OpenDBDiff: comparing SQL Server schemas and generating a sync script

A schema differ with a script as its output

OpenDBDiff is a database comparison tool for Microsoft SQL Server 2005 and later that reports schema differences and creates a synchronisation script.

That last clause is the design decision that defines the tool. The output is not a report you read and act on manually, it is a script you can review and run. That matters more than it first appears, because a schema difference report that you then have to translate into DDL by hand is a report, whereas a script is a change you can stage, review and apply the same way you would apply a migration.

The comparison is broad, and the list is the clearest statement of what the project covers. It synchronizes tables, including table options such as vardecimal and text in row. It handles columns, including computed columns, XML options and identities. It compares constraints, indexes and XML indexes, XML schemas, table types and user data types. It covers CLR objects, meaning assemblies, CLR user defined types, CLR stored procedures and CLR triggers, and plain triggers including DDL triggers. It compares synonyms, schemas, file groups, views, functions, stored procedures, partition functions and partition schemes, and it goes as far as users and roles.

Users and roles in a schema differ is unusual. Most schema comparison tools stop at tables, columns and indexes, which leaves permissions to drift silently. Comparing them means the tool can tell you that a login lost a role on one database and not on another, which is exactly the sort of difference that a deployment pipeline tends to miss.

The licence is GPL-2.0, the default branch is develop, the repository is not archived, and the last push was on 2026-10-15.

Two front ends over a shared schema layer

The repository layout is what makes this a tool rather than a script, and it separates three concerns.

OpenDBDiff.Abstractions.Schema/ holds the abstract schema model, and OpenDBDiff.SqlServer.Schema/ implements it for SQL Server. That is the layer where the object model lives: the abstraction says a schema has tables, and the SQL Server implementation says what a table with a vardecimal option is. OpenDBDiff.Abstractions.Ui/ and OpenDBDiff.SqlServer.Ui/ do the same split for the interface layer, so the WinForms front end talks to the abstraction rather than to SQL Server directly.

Then there is OpenDBDiff/ for the desktop application and OpenDBDiff.CLI/ for the command line. Having both, over a shared abstraction, is what makes the tool usable in two very different settings. A developer comparing two databases by hand wants a window with the differences presented as a tree. A deployment pipeline wants a process that exits with a diff and writes a script, with no interactive anything in the middle.

The release artifacts match. The CI build for develop is attached to every workflow run as OpenDBDiff-WinFormsGUI and OpenDBDiff-CLI artifacts, and the README notes that a run's download is kept for 14 days. The release workflow packages the two zips separately, OpenDBDiff_<version>.zip and OpenDBDiff.CLI_<version>.zip, each with a SHA256SUMS.txt.

So the two front ends are shipped as two downloads, and the schema comparison underneath them is the same code.

Building it and running the test suite

The build is the standard .NET SDK workflow, two commands:

dotnet build -c Release
dotnet test  -c Release

The target framework spread is explained in one sentence and it is the part to plan around. The test project targets net48 and net10.0, so the suite runs on Windows with both legs and on Linux with the net10.0 leg. The WinForms projects are Windows-only, while the schema libraries and the net10.0 CLI build on either platform. And dotnet build needs the .NET 10 SDK.

That gives you a clear picture of the portability envelope. The comparison engine is portable, the CLI is portable on modern .NET, and the graphical interface is not, because WinForms is. The net48 leg exists so the test suite can also run on the .NET Framework, which in practice means the core comparison logic is verified against two very different runtimes, including one where the framework's own implementation details differ.

For a team evaluating the tool, that also tells you where the risk sits. The interesting code, the schema model and the differ, is the portable part, and it is the part that is tested on both runtimes. The Windows-only surface is the presentation layer, which is the part you are least likely to be reading source for.

There is an appveyor.yml at the root alongside the GitHub Actions workflow, and the repository carries a msbuildless-net4.ps1 script, which is a reminder that this project grew up before the current tooling and still supports building the .NET Framework target without a full Visual Studio install.

The release process, written down step by step

The README documents the release procedure in four numbered steps, and for a tool that people run against production databases, that documentation is arguably as important as the code.

First, bump the version in Directory.Build.props on develop, so local builds agree with the release. Second, tag that commit and push the tag. Third, the release workflow builds, tests, packages the two zips with a SHA256SUMS.txt, attests their build provenance, and opens a draft GitHub release with generated notes. Fourth, review the notes and publish the draft.

Two details are worth pulling out. The tag wins over the property file, because the workflow passes the version explicitly, and that is what ends up in every assembly, so the recorded version of a binary always matches the tag it came from. And the workflow can be run manually with a dry run input, which builds and packages the artifacts but publishes nothing, so a release can be rehearsed before it is committed to.

The provenance attestation and the checksums file are the parts that a careful adopter should look for. A schema synchronisation script is code that will run against a database, and knowing which build produced it, and being able to check that the download is intact, is the sort of supply chain hygiene that is cheap to build in and awkward to retrofit.

The release history shows the project was quiet for a long time and then moved: v0.14.0 on 2026-10-14, with 0.13.0 and 0.12.0 both in August 2020. The v0.14.0 release came the day before the last push, and the version sits below 1.0, so the numbering still carries the weight of a pre-1.0 project.

Where OpenDBDiff is the wrong tool

The first limitation is the database. SQL Server 2005 and later, and nothing else. The abstraction layer makes the architecture extensible, and the repository is named for SQL Server in its project names, but there is no PostgreSQL, MySQL or SQLite implementation in the tree, and a comparison of a SQL Server schema against a Postgres schema is not a thing this tool does.

The second limitation is the scope of what it compares. It compares schemas, and it generates a synchronisation script for the differences it finds. It does not move data, it does not rewrite stored procedures, and it does not decide which of two definitions is correct. When it reports that a procedure differs, it gives you the text, and reconciling two versions of the same procedure is a judgement call that no schema differ can make for you. That is a feature of the design rather than a gap, but it means the tool accelerates the mechanical part of a migration and leaves the creative part to you.

The third limitation is the interface. The WinForms application is the primary way most people will use it, and WinForms is Windows only, which is consistent with a SQL Server tool but means there is no cross-platform desktop experience. The CLI covers the automation case, but the README does not describe a headless configuration format for the comparison, so driving it from a pipeline means working out how to pass the two connection targets and the output options from the command line.

The real alternative for the pipeline case is a migration framework, which differs in approach rather than in features. A migration tool owns the target state as a set of versioned scripts and works out the steps to reach it, and it holds a history of what was applied, so it can tell you what to do next and refuse to apply the same change twice. OpenDBDiff owns neither side of that: it compares two databases as they are and produces a script for the difference. For a first deployment of a schema, a migration framework is the better tool. For reconciling a database that drifted from a reference, where the reference is a live database and not a set of scripts, the diff is what you need, and OpenDBDiff is the right shape for it. The other alternative is the vendor's own comparison tooling, which for SQL Server means comparing schemas with SSMS or scripting the catalog views directly, and that is free and always matches the server version but has none of the object coverage or the sync script generation.

Editorial conclusion

Adopt OpenDBDiff if you maintain SQL Server schemas across environments and need a repeatable diff that covers more than tables and columns, since it compares constraints, indexes, XML schemas, synonyms, file groups, partitions, users and roles as well. Do not adopt it for PostgreSQL, MySQL or Azure SQL databases outside SQL Server, and do not expect it to migrate your data, because it produces a synchronisation script for schema objects. Before you run the generated script against a database, read it, and test it on a copy, since the tool's output is a script you execute rather than a change it makes itself.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-2.0
3. OpenDBDiff/OpenDBDiff on GitHub
4. README
5. Releases