SchemaSmith vs DbUp

Free, declarative state-based schema management with a standalone CLI — vs DbUp’s embedded .NET library running ordered SQL scripts.

Chaos vs Precision: Product Comparisons

Quick Summary

SchemaSmith and DbUp are both free. SchemaSmith uses a state-based approach: you declare the end state in JSON and the tool generates the changes from a standalone CLI. DbUp is a .NET library embedded in your application that runs hand-written SQL migration scripts in order. SchemaSmith covers SQL Server, PostgreSQL, and MySQL under SSCL v2.0 (source-available); DbUp is MIT-licensed open source and supports a broader set of databases including Oracle, SQLite, and Firebird.

Technical Comparison

How the tools differ in approach, features, and developer experience.

Aspect SchemaSmith DbUp
Approach State-based: declare end state in JSON, tool generates the changes Script-driven: hand-written SQL scripts applied in order
Integration Model Standalone CLI run as a deployment step .NET library (NuGet) embedded inside your application
Source Format JSON template files (one per table, view, procedure) Raw SQL files numbered or stamped for ordering
Drift Detection Built-in — compares live database to declared state on every run Not built in — DbUp tracks applied scripts, not the schema’s current shape
Environment Sync Any environment converges to the declared state in one run Replay every script from baseline, or seed the journal table at a point
Rollback Re-deploy prior release state — views, procedures, and functions restore from JSON* Hand-written down-migration scripts paired with each change
Merge Conflicts JSON template files merge cleanly in source control Script naming / numbering conflicts on parallel branches
CI/CD Model Idempotent — same result whether run once or ten times Order-dependent — the journal table tracks what has been applied
Reference Data Declarative DataDelivery blocks; two-pass FK-aware loader (DataTongs) Hand-written INSERT / MERGE scripts in the migration sequence
Failed Deployment Recovery Checkpoint & resume (--ResumeQuench); skips completed work on retry Restart from the failed script; the journal records up to the last successful one
Conditional Deployment ShouldApplyExpression — one file applies per database, env, or version Per-environment script copies, or conditional logic inside the SQL
SQL Server Availability Groups Target:SecondaryServers — primary plus secondaries quenched in parallel Run DbUp per server; orchestration is the deployer’s problem
Database Support SQL Server, PostgreSQL, MySQL (platform-specific schema definitions) SQL Server, PostgreSQL, MySQL, Oracle, SQLite, Firebird, and others via providers
Licensing Free under SSCL v2.0 (source-available); unlimited seats & schemas Free under MIT (open source)

*SchemaQuench rolls back schema by re-applying the prior release’s declared state — including stored procedures, views, and functions, which restore from JSON definitions. Data preservation (e.g., retaining values from a dropped column) is handled with user-written migration scripts inside the same package.

Production-resilience features, free

Checkpoint & resume, two-pass FK-aware data delivery, ShouldApplyExpression, secondary servers for SQL Server Availability Groups, and custom script folders all ship in the free CLI — the orchestration that DbUp users typically build around the library by hand.

Choose SchemaSmith when...

  • You want to declare schema as JSON and have the tool generate the DDL instead of writing every ALTER by hand
  • Your team regularly hits merge conflicts on numbered or stamped migration files
  • You need built-in drift detection and environment sync on every deployment
  • You want a standalone deployment step rather than a migration runner embedded inside your application
  • You need to resume a failed deployment without re-running everything that already succeeded
  • You need secondary-server support for SQL Server Availability Groups and declarative reference-data delivery
  • You want idempotent CI/CD — the same pipeline produces the same result whether run once or ten times

Choose DbUp when...

  • You want a lightweight migration runner embedded directly in your .NET application’s startup
  • You prefer full control over every SQL statement executed and the imperative ordering of changes
  • You target a database SchemaSmith does not yet cover (Oracle, SQLite, Firebird, etc.)
  • You want zero external tooling dependencies — just a NuGet package and your existing build
  • You are deeply invested in an existing DbUp migration history and want to keep the same workflow

Total Cost of Ownership

Both tools are free. The real comparison is what your team spends maintaining the workflow over time.

Factor SchemaSmith DbUp
License Free under SSCL v2.0 (source-available) Free under MIT (open source)
Migration Authoring Tool generates DDL from state diff Developer writes every script by hand
Drift Detection Built-in — runs on every deployment Not built in — the journal tracks applied scripts, not current schema shape
Rollback Authoring Schema rollback is automatic; data preservation via package migration scripts Hand-written down-migration scripts maintained alongside each change
New Environment Setup Apply current declared state directly Replay every script from baseline, or seed the journal at a starting point
Script Maintenance JSON template files are the source of truth; no script archaeology Grows linearly with project lifetime as the script directory accumulates

What you trade

DbUp is a strong fit for projects that want a small, embedded migration runner inside a single .NET application. SchemaSmith is the better fit when the maintenance cost of hand-written scripts — ordering conflicts, drift, rollback authoring, new-environment replay — starts to outweigh the appeal of full per-script control.

Migrating from DbUp

Switching from DbUp to SchemaSmith does not require rewriting your migration history. Extract current state once, review the generated JSON, and start managing future changes declaratively.

  1. Extract current state with SchemaTongs. Point it at a representative database and let it capture every table, view, procedure, and function as JSON template files.
  2. Review the generated metadata. The JSON files become the new source of truth — commit them to source control alongside the rest of your repo.
  3. Deploy with SchemaQuench. Future schema changes are edits to the JSON; SchemaQuench generates and applies the DDL on every run, idempotently.

Your existing DbUp script directory stays in place as a record of how the database got here. SchemaSmith takes over from the current state forward.

Pricing and feature data last verified May 2026. Competitor information may change.