Database DevOps in SQL Server Management Studio is now generally available. The feature landed in SSMS 22.10.2, released September 28, 2026, and it means something specific: SSMS finally supports SDK-style SQL database projects built on the Microsoft.Build.Sql SDK, so schema changes can live in source control and flow through CI/CD like any other code.
If you have spent years watching DBAs keep schema in their heads and ad hoc scripts in a shared folder, this is the fix. The tool they already open every morning now speaks the same language as the app developers down the hall.
What a SQL database project actually is
A SQL database project is a local representation of a database: tables, stored procedures, functions, views, all as .sql files on disk. Per Microsoft’s Database DevOps documentation, building the project validates the T-SQL against the target platform and produces a .dacpac artifact. Publishing that artifact is idempotent, so the same file can be deployed repeatedly across dev, staging, and production without hand-holding.
That last part matters more than it sounds. When the deployment path from a developer’s laptop and the deployment path from a pipeline are literally the same artifact, drift stops being a mystery. The schema in prod is either what the project says or it is not, and schema compare will tell you which.
The projects run on Microsoft.Build.Sql, an MSBuild SDK similar to Microsoft.NET.Sdk. It needs .NET 8 or higher, and the current SDK version is 2.3.0. The SQL files glob in by default, which means adding a table is usually just dropping a file in the right folder. Under the hood everything runs on the DacFx .NET library, and targets include SQL Server, Azure SQL Database, Azure SQL Managed Instance, and SQL database in Fabric.
Preview to GA: what actually changed
The public preview arrived with SSMS 22.4 in March 2026. Between then and GA, the workload picked up the pieces that make it usable day to day. Schema compare, which needs SSMS 22.7 or later, can diff databases, projects, or .dacpac files and either apply selected changes or generate a script. The publish dialog grew SQLCMD variable support and advanced settings. You can create a project from an existing database, and there are 74 new item templates, NuGet package references for database references, and support for .scmp and .publish.xml files in Solution Explorer.
One gap to know about: SSMS only supports the SDK-style project format. Original Visual Studio SQL projects have to be converted before SSMS will open them. And if your team still lives in Visual Studio, note that SSDT in Visual Studio 2026 supports only the original format, with no Microsoft.Build.Sql support announced. The SDK-style projects are clearly the strategic direction, but the tooling story across the two IDEs is not symmetric yet, so check your team’s editor before committing to a migration.
The CI/CD loop
The pipeline story is plain MSBuild. Build the .sqlproj with dotnet build, get a .dacpac, then deploy it with SqlPackage’s /Action:Publish or the azure/sql-action@v2 GitHub Actions task. Microsoft’s tutorial walks through the whole path.
If you are starting from an existing database rather than a greenfield project, SqlPackage can extract the schema into organized .sql files with /Action:Extract and /p:ExtractTarget=SchemaObjectType. Commit that, and you have a baseline in version control in an afternoon.
Why this lands well
Database-as-code has existed in various forms for a decade, but adoption usually stalls because the DBA’s tool of choice could not participate. That was always the weak link in Redgate-style workflows: sooner or later someone opened SSMS, made a change by hand, and your beautiful project file became a lie. Schema compare in the same tool narrows that escape hatch. You can compare a live database against the project, apply the missing pieces, and save the comparison as an .scmp for the next drift check.
There is also a quiet interoperability win here. Because the project format is the same across SSMS, VS Code’s MSSQL extension, and SqlPackage, a mixed team can share one repo. The DBA reviews schema in SSMS, the app developer tweaks a view in VS Code, and the pipeline deploys whatever both of them committed. Nobody has to switch tools.
Getting started
Update to SSMS 22.10.2 or later, install the Database DevOps workload through the SSMS installer, and make sure you have the .NET SDK 8 or higher. The workload and SSMS itself are free, and no new licensing came with the GA announcement. Project work happens offline, so you do not need a live connection to build or edit.
Be realistic about parity, though. SSMS’s project support does not include everything Visual Studio SSDT offered over the years, and Microsoft’s own notes list feature gaps. Evaluate against your actual workflow before you migrate anything critical. For greenfield Azure SQL work, though, this is now the obvious default: schema in git, reviewable pull requests, and a .dacpac that deploys the same way everywhere.