How it compares — SQL Deploy

How to read this

Every tool here does something SQL Deploy does not, and the tables are meant to help you decide whether it replaces what you use, sits beside it, or does not fit. The gaps are in the tables rather than in a footnote.

Three caveats first:

What is written about the other tools is their well-known capability, taken from their public documentation, not from a bench test of every row. They all move; check anything you are about to decide on.
SQL Deploy is a state-based tool for SQL Server. It compares files to a database and deploys the difference. A migrations framework answers a different question — "which numbered scripts have not run here yet?" — and the rows about history and versions are where that shows.
A blank cell is a blank cell. Where SQL Deploy does nothing, the row says so.

● yes · ◐ partly, or with conditions · blank: no.

The deployment itself

	SQL Deploy	SSDT / sqlpackage	Redgate SQL Compare	Flyway	DbUp	Re-run every file	SQL Workbench
Deploys only the objects that differ	●	●	●				●
Keeps `modify_date` meaningful on untouched objects	●	●	●	◐	◐		●
Script you can read before anything runs	●	●	●	● your own	● your own	◐	●
The script runs in any SQL client, no tool needed to apply it	●	◐ sqlcmd mode	●	◐	◐	●	◐
One transaction, rolled back on any failure	●	◐ option	●	◐ per migration	◐ per script	◐	●
Stops itself before losing data unless told otherwise	●	●	●				●
Never drops what is not in source	●	◐ option	◐ option	◐	◐	●	◐ asks
Progress visible while it runs, in any client	●	◐	◐			◐	◐

Scope

	SQL Deploy	SSDT / sqlpackage	Redgate SQL Compare	Flyway	DbUp	Re-run every file	SQL Workbench
Procedures, functions, views, triggers	●	●	●	◐ written by you	◐ written by you	●	●
Tables, indexes, constraints, types	●	●	●	◐	◐		●
Reference data as files, rows that differ	●	◐ post-deploy scripts	◐ separate product	◐	◐		●
Permissions, extended properties, ownership		●	●	◐	◐	◐	◐
A repository that owns only part of a schema	● merge mode	◐	◐	●	●	●	◐
Several databases and servers in one release	●	◐	◐	●	●	◐	◐
SQL Server	●	●	●	●	●	●	●
PostgreSQL, MySQL, SQLite, Oracle			◐	●	◐	◐	◐

Process

	SQL Deploy	SSDT / sqlpackage	Redgate SQL Compare	Flyway	DbUp	Re-run every file	SQL Workbench
State in the repository, difference computed	●	●	●				●
Ordered migrations with a version table			◐ with Flyway	●	●
Validate on every pull request without a database write	●	●	◐	●	◐		●
One manifest, one environment file per target	●	◐ publish profiles	◐	●	◐	◐	● aliases
Secrets never in the file	●	◐	◐	●	◐	◐	●
Detects drift since the last deployment		●	◐	◐			●
Byte-identical output for an unchanged database	●	◐	◐	●	●	●	◐

The people in front of it

	SQL Deploy	SSDT / sqlpackage	Redgate SQL Compare	Flyway	DbUp	Re-run every file	SQL Workbench
Desktop application with the plan and the diffs	●	◐ Visual Studio	●	◐ Flyway Desktop			●
Per-object choice of what goes into this run	●	◐	●				◐
Environment rules that stop a click deploying to production	●		◐				●
Command line for the pipeline	●	●	●	●	●	●	●
Windows and Linux	●	●	◐ Windows	●	●	●	●
Free to use	●	●		◐ community	●	●	●

Where SQL Deploy loses

You want a history. If your process is "every change is a numbered script, applied once, in order", Flyway or DbUp is the right shape and SQL Deploy is the wrong one.
You deploy permissions, or you need the tool to drop things. It does neither, on purpose.
Your database is not SQL Server.
You want drift detection. sqlpackage can block a deployment when the target has changed since the last one; SQL Deploy compares when asked and remembers nothing.

Where it sits beside something

SQL Deploy and SQL Workbench share an author and a view of the problem, and are used together: SQL Workbench for the interactive work — browsing, querying, comparing any two sources on any of its engines — and SQL Deploy for the release, where the manifest in the repository, the environment file and the pipeline decide what happens, and the script is the artifact that gets reviewed.