Why your database schema belongs in Git

iqrashaikh

Microsoft Employee

5 months ago

Author: Iqra Shaikh - Product Manager 2

At SQLCon this year, a room full of SQL developers was asked two questions.

How many already have their databases under source control? Some hands went up.

How many want their databases under source control? Every hand in the room went up.

Most teams already use Git for application code. Fabric lets you use the same workflow for your database schema.

SQL database in Microsoft Fabric ships with built-in Git integration. You can manage schema changes the same way you manage application code. It doesn’t introduce a new workflow, but it extends the one your team already uses.

Your app code is already in Git. Schema changes can be too. That gives you the same benefits: pull requests, code review, history, and rollback. This is what Fabric's source control integration unlocks. You don’t need a new process, just extend your existing workflow to include the database.

Figure: Put your database schema in the same repo as your app code, then ship changes through pull requests - all inside your Fabric workspace.

The gap most teams are living with

If you build applications, your workflow probably feels natural at this point. A change goes into a branch, gets reviewed in a pull request, and deploys through a pipeline. You have a record of every change, who approved it, and when it went out.

Database development often works differently. Schema changes often happen directly on the server or get exported as a script and run manually. There is no branch, no review, no history. When something breaks, the application side of the incident is traceable. The database side is a mystery.

Most teams have been here: something breaks in production, the logs point to the database, and nobody can say with confidence what changed last night. There is no history to check. No pull request to review. You just ask around and hope someone remembers.

This isn’t usually a tooling problem; it’s how the workflow is set up. Fabric's built-in Git integration closes that gap.

What changes when you use Git

When you connect your SQL database in Fabric to a Git repository, your database schema lives in your repo as SQL files, alongside your application code, subject to the same review process, tracked in the same history. Fabric supports both GitHub and Azure DevOps repositories.

In practice: Your team works in VS Code with app code and schema side by side. A developer makes a schema change as a SQL file, commits it to a branch, and opens a pull request. The team reviews it just like application code. When it is approved, the change is applied to the SQL database in the Fabric workspace. SQL Database Projects structure and validate your schema, but the core value is simpler: your existing workflow now covers the database too.

For the full setup, refer to the SQL database in Microsoft Fabric source control integration documentation.

Why this matters

Version control for databases isn’t just about history. It changes how teams approach schema changes.

When a schema change has to go through a pull request, it gets reviewed before it reaches production. Someone reads it. Someone asks whether it handles the edge cases. Someone notices the missing index. That review step catches problems earlier, before they reach production.

It also changes incident response. When something breaks, you can trace exactly what changed and when.

And it changes how confidently teams ship. Schema changes that used to feel risky because they were irreversible and unreviewed became just another pull request. The database stops being the scary part of deployment.

This matters even more as AI tools start generating schema changes. When Copilot scaffolds a table or suggests a stored procedure, that change needs the same review as any other code change. A pull request is how you keep a human in the loop. The database schema is no exception.

How this works in practice

Someone needs to add a table. They create a SQL file in VS Code, define the table, and build the project to catch issues early. They commit to a branch and open a pull request. The team reviews the schema change alongside the related application code. Once approved, the change is applied in Fabric and validated from Git instead of run manually.