If you haven’t already, check out Arun Ulag’s hero blog “FabCon and SQLCon 2026: Unifying databases and Fabric on a single, complete platform” for a complete look at all of our FabCon and SQLCon announcements across both Fabric and our database offerings.
Database changes shouldn't be the last manual step in your release process. As teams adopt DevOps practices to ship application code faster and more reliably, the database has remained a sticking point—manual scripts, inconsistent deployments, and limited visibility into what changed and when. SQL projects change that by making database schema a first-class citizen in source control, CI/CD pipelines, and collaborative development workflows.
We're announcing several milestones that bring this vision closer to reality across the Microsoft SQL ecosystem. SQL projects are available in SQL Server Management Studio (Preview), the SQL projects experience in VS Code has expanded with a publish dialog and rich schema compare (Generally Available), and SQL database in Fabric has gained pre-deployment and post-deployment script support for its built-in CI/CD capabilities. Whether you're running SQL Server on-premises, Azure SQL in the cloud, or SQL database in Fabric, SQL projects provide a unified, readable format for managing your database alongside your application code—using the tools and pipelines you already have.
Understanding Database DevOps: A modern approach to SQL projects
Database DevOps tooling for Microsoft SQL continues to expand and evolve, with SQL projects playing a central role in enabling database professionals to adopt DevOps practices and automate their workflows. SQL projects provide a structured way to manage database schemas, scripts, and related artifacts, allowing teams to version control their database code, collaborate effectively, and implement continuous integration and deployment processes that include the database.SQL projects represent a fundamental file format for database development and automation, enabling both a declarative approach to defining and deploying database schemas as well as supporting migration-based deployment methods with consolidated change visibility and code quality checks. By adopting SQL projects, teams can achieve greater consistency, collaboration, and efficiency in their database development processes, ultimately leading to more reliable and maintainable database systems. The integration of SQL projects with modern development tools and platforms further enhances their value, making it easier for teams to implement DevOps practices and automate their database workflows.
Figure: SQL database project conceptual diagram.
Building a SQL project validates the syntax is correct and all the object relationships are valid and produces a dacpac which is a compiled version of the database schema. The dacpac can then be deployed to a target database, where the deployment process will compare the schema in the dacpac with the schema in the target database and generate a deployment plan that includes the necessary changes to bring the target database in line with the schema defined in the project.
This process allows for both declarative and migration-based approaches to database development, as teams can choose to either define their desired end state in the project or manage incremental changes through scripts while still benefiting from the validation and deployment capabilities of SQL projects.
Streamlined SQL projects: Fabric CI/CD and SQL database in Fabric
While SQL projects are a shared format for Microsoft SQL - including SQL Server, Azure SQL, and SQL in Fabric - we're going to start our exploration in SSMS from a SQL project that was created by committing our SQL database in Fabric to source control. This capability is available directly from the Fabric portal, where you can connect your SQL database to a GitHub or Azure DevOps repository and it will automatically create a SQL project with the latest schema from your database and commit it to the repository. This is a great way to get started with SQL projects and see how they can help you manage your database schemas in source control.Because the SQL project format supports not only the declarative .sql files but also the .dacpac format and dynamically generated SQL deployment scripts, we are able to both branch and merge our database in Fabric. Branching the workspace creates a new branch in source control with the latest state of the database and a new development environment that has been deployed from that SQL project. This allows us to work on changes in isolation and then merge those changes back into the main branch when we're ready. The merge process is navigated through the pull request interface in GitHub or Azure DevOps, where you can review the changes, see the impact on the database schema, and then approve and merge the changes when you're ready.
The changes can be applied to the database directly from the Fabric portal, or you can generate and manually review the deployment script before applying it with any one of the SQL projects ecosystem tools, giving you confidence and control over the changes being made to your database.
Figure: SQL database in Fabric web editor with Shared queries and static data being set as a post-deployment script.
Recent updates to CI/CD for SQL database in Fabric include pre-deployment and post-deployment scripts, which allow you to include custom SQL scripts that run before or after the main deployment plan during a deployment. Pre-deployment and post-deployment scripts run as part of updating from source control, branching, and deployment pipelines in Fabric. This functionality is particularly useful for handling development scenarios that may require additional setup or cleanup steps, such as data cleanup or static data management.
To add a pre-deployment or post-deployment script in Fabric, you will create the T-SQL script in the Fabric editor and set it as a "Shared Query." From the "Shared Queries" folder on the database the query can be marked as a pre-deployment or post-deployment script. Pre-deployment and post-deployment scripts in Fabric are the same pre-deployment and post-deployment scripts known to SQL projects users and are compatible with the SQL projects tooling, including the SqlPackage CLI and automation environments. SQL projects and CI/CD with SQL database in Fabric provide a streamlined way to manage your database schemas without taking away the flexibility of the core SQL projects format and ecosystem.
Learn more about pre-deployment and post-deployment scripts with SQL database in Fabric in the source control documentation.
SQL Projects in SSMS: A New Era for Database Development
With the 22.4 release of SQL Server Management Studio (SSMS), we are launching SQL projects with the new "Database DevOps" workload in SSMS (Preview). This marks a significant milestone in our journey to bring the power of SQL projects to database professionals in different roles and with different preferences for development environments.The initial preview brings the core create, build, and publish workflow to SSMS with the backing of Microsoft.Build.Sql projects, which are also supported in VS Code. This means that you can create a SQL project in SSMS, check it into source control, and then work with it in VS Code or vice versa, enabling a seamless experience across different tools and teams.
Figure: SQL Server Management Studio 22 installer and workload configuration.
The repository we're using with our SQL database in Fabric can be cloned to our local machine, and when we open the SQL project in SSMS, we see the familiar folder structure with our database objects represented as .sql files in "Solution Explorer". From there, we can make changes to our database schema by editing the .sql files in the project and then use the build and publish capabilities in SSMS to deploy those changes back to our SQL database in Fabric or to any other target database.
This workflow allows us to manage our database schemas in a more structured and collaborative way, while also leveraging the familiar environment of SSMS for our database development work. The "Properties" menu item on the project gives us access to enable or configure additional capabilities such as SQL code analysis rules, which provide code quality feedback during the build process.
When we create a new SQL project in SSMS, the default target platform is SQL Server 2025 - representing the validated set of T-SQL syntax and features that are checked during project build. The target platform can be changed in the project properties dialog, giving us an easy way to check if our database is compatible for deployment to different versions of SQL Server, Azure SQL Database, or SQL database in Fabric.
The project properties in SSMS also include access to the SQLCMD variables, which create flexibility in parameterizing our database objects until deployment time. This is particularly useful for managing environment-specific differences, such as the endpoint value for the stored procedure sp_invoke_external_rest_endpoint, without having to maintain separate versions of our database objects for each environment. By using SQLCMD variables, we can keep our database code clean and maintainable while still supporting the necessary variations across different deployment targets.
Figure: Code analysis in SQL projects can catch common antipatterns in database code.
This is just the beginning of our plans for SQL projects in SSMS, and we are committed to expanding the capabilities and integrations in future releases based on your feedback and needs. Additional functionality in upcoming releases include creating and updating projects from databases directly as well as the graphical schema compare interface.
If you're looking to bring an existing database into source control and start with SQL projects in SSMS today, you have two options for quickly accessing your database definition. The mssql extension in VS Code provides a menu item in object explorer for "Create project from database" and the SqlPackage CLI has a command to generate the .sql files that can be copied directly into the SQL project directory:
```sql dotnet tool install -g microsoft.sqlpackage sqlpackage /action:extract /sourceconnectionstring:"<connection string>" /targetfile:"databasefiles" /p:extracttarget=schemaobjecttype ```
Solution_explorer_in_SSMS_with_a_SQL_project_for_AdventureWorks_open._Folders_fo
Figure: Solution explorer and SQL projects in SSMS.
SSMS is a critical part of the SQL project experience, especially for those who prefer a database-focused development environment or who are deeply integrated with other SSMS features. By bringing SQL projects to SSMS, we are empowering more database professionals to engage with their organization's DevOps processes.
Learn more about the 22.4.1 release of SSMS in the SSMS blog post.
Enhancing SQL Projects in VS Code: Publish Dialog and Schema Compare
The MSSQL extension for VS Code includes several features for developing your database-connected applications, including support for Microsoft.Build.Sql projects, schema compare, schema designer, and GitHub Copilot integrations. The .dacpac and .bacpac wizard ("Data-tier applications") was recently added, providing a graphical interface for creating and deploying .dacpac and .bacpac packages. The .dacpac file defaults to a iterative deployment approach where the .dacpac can be applied to an existing database to "upgrade" the database to a new version of the objects.In contrast, the .bacpac file is focused on capturing a snapshot of the database schema and data at a point in time, which can then be deployed to create a new database as a full copy of the original database. The wizard provides a streamlined experience for both scenarios, making it easier to manage your database environments directly from VS Code.
On the SQL Projects side, the Publish dialog has graduated out of preview and is designed to streamline deploying a .sqlproj to a target Microsoft SQL database. It walks you through connection selection, advanced property selection, and lets you review the equivalent SqlPackage command, so you get both a predictable, safe workflow in the editor and reusable CLI commands for CI/CD. The publish dialog in VS Code also supports generating a deployment script for review before applying the changes to the target database, giving you confidence and control over your deployments.
Successfully leveraging SQL projects in your organization
SQL projects are built to let teams add features one step at a time, so there's no need to use every capability immediately. These projects are flexible—they adapt to a team's current needs and can scale up as the team evolves. The following are some typical ways teams get started:- Start with source control. Even before automating deployments, simply putting your database schema into a SQL project and committing it to Git gives you change history, diff visibility in pull requests, and a single source of truth for your schema. For teams on SQL database in Fabric, this is as simple as connecting your database to a repository from the Fabric portal.
- Add build validation. Once your SQL project is in source control, adding a build step to your CI pipeline takes minutes with `dotnet build`. This catches syntax errors, broken references, and code analysis violations on every pull request—well before anyone attempts a deployment.
- Automate deployments. When you're ready, the SqlPackage CLI or the publish dialog in VS Code and SSMS let you deploy to any target with a repeatable, auditable process. Generate the script first, review it, and then apply—or automate the whole flow for non-production environments where speed matters most.
- Enforce standards. As your team matures, add custom code analysis rules to enforce naming conventions, performance patterns, or security policies. These rules run automatically on every build, making governance a default part of your workflow rather than a gate at the end.
Get started with SQL projects in SSMS (Preview), explore the expanded capabilities in VS Code, and try the streamlined CI/CD experience in SQL database in Fabric. Documentation is available and our public roadmap shows what's coming next.
We'd love to hear your feedback! The SQL projects roadmap not only provides a look at our upcoming plans but creates a conduit for you to chime in on areas that you’re most interested in. Your input directly shapes our priorities and helps us build the database DevOps experience that works best for your teams.