Earlier this year, we introduced SQL projects in SSMS with the Database DevOps workload, which brought the core create, build, and publish workflow to SQL Server Management Studio.

With SSMS 22.7, we're expanding that foundation with two capabilities that database professionals have been asking for in SSMS: graphical schema compare and a built-in SQL formatter. In addition to those key features, we're continuing to expand the SQL projects support in the Database DevOps (Preview) with SQLCMD variable support in the publish dialog.

These features make it easier to adopt database DevOps practices without leaving the tool you already know.

Schema compare (Preview)

Schema compare is one of the most requested capabilities for SQL projects in SSMS, allowing you compare two database definitions. The "database definitions" come from the source and target, which can be any combination of a connected database,

SQL database project, or .dacpac file. In schema compare, you interact with the differences as a set of actions needed to make the target match the source, very similar to a git diff view.

Figure: Schema compare visually contrasts sets of database objects, pulling from databases, SQL projects, or .dacpac files.

The workflow is straightforward. Select your source and target, run the comparison, and review the results in a grid that groups differences by action type: adds, changes, and deletes. Each row in the results represents a database object that differs between the two definitions, and you can drill into the details to see the per-line T-SQL differences with either side-by-side or inline differences. From there, you selectively include or exclude changes per-object, then either generate an update script for review or select Apply to update the target directly.

Where schema compare becomes even more powerful for ongoing development is with .scmp files. A schema compare file saves the full comparison definition (source and target connections, comparison options, and excluded object types) so you can rerun the same comparison later with a single selection.

For example, if your workflow involves regularly syncing changes between a development database and your SQL project, saving an .scmp file turns that into a repeatable, consistent process. Schema compare options let you make granular adjustments to the comparison engine, from ignoring whitespace and column order to controlling whether indexes not in the source are dropped, giving you the level of control you need for each environment.

Learn more in the schema compare documentation.

SQL formatter (Preview)

Consistent formatting makes T-SQL easier to read, review, and maintain, especially when multiple people are contributing to the same SQL project. SSMS 22.7 introduces a built-in SQL formatter that you can access directly from the right-click context menu on any T-SQL editor window.

The formatter supports a range of options that let you control how your SQL is styled. You can configure keyword casing (uppercase, lowercase, or PascalCase), indentation size, semicolons after statements, and how clauses like FROM, WHERE, and JOIN are broken across lines. Alignment options let you line up clause bodies, column definitions, and SET clause items for a clean, readable layout. Multi-line list options control whether SELECT columns, WHERE predicates, and INSERT values each get their own line.
Figure: T-SQL code is more readable when consistently formatted, and the Format SQL context menu option will apply customizable formatting rules to your code.

For SQL projects, the formatter integrates with format on save. When the "Format on Save" option is enabled in your SSMS, every time you save a .sql file in your project, it's automatically formatted according to your configured options. This keeps your project files consistent without any extra effort, which is especially valuable when changes flow through pull requests and code reviews.

We're continuing to expand the available options, and we encourage you to file feedback if there's a formatting behavior you'd like to see. The SQL formatting functionality in SSMS is built on top of the open-source .NET library for T-SQL parsing, ScriptDOM, also known as SqlScriptDOM. Get to know ScriptDOM in its GitHub repository, where the GitHub issues system can be used to discuss ideas and challenges encountered and pull requests are welcome.

Learn more in the SQL formatter documentation.

SQLCMD variables

Real-world deployments rarely target a single environment. Connection strings, feature flags, and environment-specific values all need to change between dev, test, and production, but you don't want to maintain separate copies of your database code for each one. SQLCMD variables solve this by creating dynamically replaceable tokens in your SQL objects and scripts, with values set at deployment time.

To add a SQLCMD variable to your project in SSMS, select the project in Solution Explorer and select Properties. In the SQLCMD Variables section, specify the variable name and optionally a default value.

Figure: Project properties include SQLCMD variables, expanding the flexibility of your project deployments.

The variable is defined in your .sqlproj file:

<ItemGroup>
    <SqlCmdVariable Include="EnvironmentName">
        <DefaultValue>staging</DefaultValue>
        <Value>$(SqlCmdVar__1)</Value>
    </SqlCmdVariable>
</ItemGroup>

Once defined, you reference the variable in any SQL script using $(variableName) syntax. For example, you might conditionally execute setup logic based on the target environment:

IF '$(EnvironmentName)' = 'testing'
BEGIN
    -- insert test seed data
END

Figure: Based on the inputs to the publish dialog, SSMS will calculate the dynamic deployment plan for your project. The same process can be done via the SqlPackage CLI in CI/CD pipelines.

New in SSMS 22.7, the Publish dialog now surfaces SQLCMD variables so you can set their values directly when deploying from SSMS. Quick deployments can be accomplished without the use of a command-line. When you are ready to use a command-line tool for automated pipelines and CI/CD, SqlPackage supports the same variables with the /v option:

sqlpackage /Action:Publish /SourceFile:AdventureWorks.dacpac /TargetConnectionString:{connection_string} /v:EnvironmentName=production

SQLCMD variables keep your database code flexible and maintainable while supporting the necessary variations across deployment targets. Whether you're parameterizing an endpoint for sp_invoke_external_rest_endpoint or toggling behavior between environments, you define the variable once in the project and supply the value at deploy time.

Learn more in the SQLCMD variables documentation.

What's next and how to share feedback

These features in SSMS 22.7 are part of an ongoing investment in making database DevOps practical and accessible. Our quarterly roadmap shows what's coming next across the SQL projects ecosystem. We're continuing to release SSMS with new database DevOps features and ongoing improvements to existing functionality.

Explore the documentation for all SQL projects capabilities and try schema compare, the SQL formatter, and SQLCMD variables in SSMS 22.7. Let us know what you think. Your feedback directly shapes what we prioritize — submit SSMS feedback through Help > Send Feedback in SSMS or via the Developer Community feedback channel.