SQL Deploy is for teams whose stored procedures, functions, views, triggers, tables and
reference data live as .sql files in a repository, and who need to get a release of those
files onto a database — reviewed first, and with a record of exactly what changed. It is a
release tool, not an editor: the work of writing the SQL happens elsewhere, and SQL Deploy's job
begins when a branch is ready to go out.
The developer who owns the database code. You keep procedures in folders, one object per
file, and you want a deployment to be the diff between the repository and the database — not a
thousand CREATE OR ALTER statements that re-stamp every object's modify_date and bury the
three that actually changed. You want to read the script before it runs, and to hand it to
somebody else with confidence that it will behave the same in their client as in yours.
The DBA who approves releases. You are given a script and asked to run it. You want it to be plain T-SQL with no client-specific directives, to run in one transaction, to stop itself rather than drop a column with rows in it, and to say — clearly, at the end — whether it committed or rolled back and why. You want the same script to work in a query window and in a pipeline.
The release engineer. You want the deployment to be an artifact the pipeline produces, versioned with the commit it came from, validated on every pull request, and applied by the same tool or by whatever already applies scripts in your organisation.
What it is not
- Not a migrations framework. There is no version table and no ordered history of change scripts. The repository holds the desired state of each object, and the tool works out the difference. Teams that want Flyway- or DbUp-style numbered migrations want a different tool.
- Not a schema compare GUI. The desktop application shows the plan and the diffs for the deployment in front of you; it is not an ad-hoc compare-anything tool. For that, including other engines, there is SQL Workbench from the same stable.
- Not multi-engine. SQL Server only. The comparison rules, the schema model and the script it writes are all T-SQL.
- Not an eraser. Objects that exist in the database but not in the repository are reported and left alone. Removing something is a decision for a person, and the tool will not make it.
- Not a permissions or ownership tool. Object permissions, extended properties and ownership are outside the comparison and are never touched.
- Not drift detection. It compares when asked; it does not record what it deployed in order to notice an out-of-band change later.