Getting Started with SchemaSmith for SQL Server

By the end, you'll have completed the full SchemaSmith cycle — and you'll understand why teams stop writing migration scripts once they've seen this. This walkthrough uses the Northwind demo database on SQL Server. PostgreSQL and MySQL have their own Getting Started walkthroughs if you're running those engines.

You need three things:

SchemaSmith tools. Download self-contained ZIP packages from the latest GitHub release and extract them anywhere on your PATH. No .NET runtime required.

A database server. Either an existing SQL Server instance or Docker (recommended). The repository includes a Docker Compose file that starts the demo server for you.

The demo files. Clone the repository or download just the Demos/ folder:

git clone https://github.com/Schema-Smith/SchemaSmith.git
cd SchemaSmith

Now let's go the other direction. Pretend you already have a database and want to bring it under SchemaSmith management. SchemaTongs grips your live schema and casts it into structured files. Create a SchemaTongs configuration file called tongs-extract.json:

{
  "Source": {
    "Platform": "SqlServer",
    "Server": "localhost,1440",
    "User": "TestUser",
    "Password": "your-password-here",
    "Database": "Northwind",
    "ConnectionProperties": {
      "TrustServerCertificate": "True"
    }
  },
  "Product": {
    "Path": "./my-northwind",
    "Name": "Northwind"
  },
  "Template": {
    "Name": "Northwind"
  },
  "ShouldCast": {
    "Tables": true,
    "Schemas": true,
    "UserDefinedTypes": true,
    "Functions": true,
    "Views": true,
    "Procedures": true,
    "TableTriggers": true,
    "Catalogs": true,
    "StopLists": true,
    "DDLTriggers": true,
    "XMLSchemaCollections": true,
    "IndexedViews": true
  }
}

Run the extraction:

SchemaTongs --ConfigFile:tongs-extract.json

Look at what appeared in the my-northwind/ folder. You now have a complete schema package:

my-northwind/
  Product.json                     ← Platform, templates, tokens
  .json-schemas/                   ← JSON Schema validation, generated on the fly
  Templates/
    Northwind/
      Template.json
      Tables/
        dbo.Categories.json
        dbo.Customers.json
        dbo.Orders.json
        ... (13 tables)
      Views/
        dbo.Alphabetical list of products.sql
        ...
      Procedures/
        dbo.CustOrderHist.sql
        ...
      Schemas/
      Functions/
      Triggers/
      Table Data/

Every table is a JSON file describing its columns, indexes, and constraints. Every stored procedure and view is a plain SQL file. This is your entire database — materialized as readable, diffable, reviewable source files. Commit this to source control and you have a complete history of every schema change from this point forward. For the full set of extraction options, see the SchemaTongs reference.

That's the cast. A live database, captured in files you can read, review, and version.

Here's where it gets powerful. You just extracted the live Northwind schema into my-northwind/. Now let's quench that package back at the same database to prove the round-trip — declared state in, target verified against it, exact-delta DDL out. Create a SchemaQuench configuration file called quench-deploy.json:

{
  "Target": {
    "Server": "localhost,1440",
    "User": "TestUser",
    "Password": "your-password-here",
    "ConnectionProperties": {
      "TrustServerCertificate": "True"
    }
  },
  "WhatIfONLY": false,
  "SchemaPackagePath": "./my-northwind",
  "ScriptTokens": {
    "NorthwindDb": "Northwind"
  }
}

Notice the ScriptTokens section: SchemaQuench resolves the {{NorthwindDb}} token in the package's scripts to Northwind, the database we want to manage. Tokens parameterize a package so the same source files can deploy to dev, staging, and production by changing one value at deploy time — point a token at a different database name to spin up a clone for testing without touching another file. You'll learn more about tokens in Products and Templates, and the full token system is documented in Script Token Mechanics.

Run the deployment:

SchemaQuench --ConfigFile:quench-deploy.json

SchemaQuench reads the schema package, connects to the live Northwind database, and compares your declared state to what's actually there. Since you just extracted this package from that exact database, the two are in sync — no DDL is emitted on this first run. That's the point: SchemaSmith only changes what's actually different. The diff comes alive in the next step.

One package. One command. A target verified against your declared source of truth. That's what quenching looks like.

Connect to the database with whatever SQL client you prefer and look at the Shippers table:

SELECT TOP 1 [CompanyName], [Phone], [Email] FROM [dbo].[Shippers];

The Email column is there, right where you declared it. The file is the truth, the database matches, and your next commit records the change for posterity.