Schema Migration: SQL Server Data Tools vs Liquibase and Flyway
SSDT is comparable to Liquibase/Flyway as it does what they do but by taking a different approach. With SSDT you have the development environment so you get things like go to definition, find references and intelli-sense as well as the ability to compile a project into a dacpac and then deploy that dacpac to a database.

The SSDT way (and redgate sql compare way) to do a deloyment is to declare what you want so if you want to change a table that looks like:

create table a(id int)


to a table that looks like:

create table a(id int, another_column varchar(12))


with SSDT you just change your table definition to the second one and let SSDT worry about how to upgrade it (can it do an alter table, add column or does the column order change so you will need to rebuild the table etc).

With Liquibase (DbUp, ReadyRoll, manual methods etc) what you do is in this case have to write the alter table yourself and make sure that you run the scripts in the correct order, consider this scenario:


Release 1 - create column hello on table
Release 2 - rename column hello to joe_blogs
Release 3 - rename column joe_blogs to hello
Release 4 - create column joe_blogs


If any of the releases are missed, none of the next ones can continue. 

Benefits of upgrade scripts (Liquibase, DbUp, etc):


You have complete control over the scripts
DBA's / Developers are used to this


Benefits of compare / merge (SSDT, Redgate SQL Compare):


Do not have to write upgrade scripts
It is easy to get to any specific version just compare and merge that version


Drawbacks of upgrade scripts:


Must be run in order
Rely on humans no making mistakes
Can be slow especially if you have a lot of changes
Unless your team is very disciplined databases in different environments (dev, test, staging, prod etc) often become out of sync making any testing invalid
Downgrading a release means writing the reverse of all the scripts you have already written


Drawbacks of using compare / merge:


Tools are not 100% trusted, perhaps unfairly
SSDT requires a working project, many many databases have code that doesn't actually compile or run (think dropped tables but not procedures etc), I have seen this in about 8/10 databases I have inherited :)
Many DBA's / developers are hesitant to give up developing in SSMS / notepad


Personally I really think SSDT is a professional development environment and it means that I can concentrate on writing useful code and tests rather than writing upgrade scripts which are in themselves just a means to an end.

You asked for opinions so there you go :)

ed