MySQL Walkthrough

SchemaTongs Walkthrough — MySQL

Point SchemaTongs at a MySQL database, extract the live schema into structured JSON and SQL files, and explore the package ready for version control — the cast leg of the SchemaSmith cycle in 10 minutes.

Prerequisites Start the demo environment Cast with SchemaTongs Explore the package
SchemaTongs: extracting a live MySQL database into structured files

SchemaTongs grips your live schema and casts it into structured files.

Prerequisites

You need three things before starting the walkthrough — the SchemaSmith binaries, a MySQL server you can read from, and the demo schema package this walkthrough drives.

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 MySQL instance or Docker (recommended). The SchemaSmith 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/SchemaSmithyFree.git
cd SchemaSmithyFree

Step 1: Start the Demo Environment

Each platform has its own demo folder under Demos/ with a run-demo launcher, a docker-compose.yml, and a .env credentials file. From the repository root, launch the MySQL demo:

cd Demos\MySQL
run-demo.cmd
cd Demos/MySQL
./run-demo.sh

The launcher runs build-schemaquench.sh to compile the SchemaQuench binary (requires the .NET SDK on the host), then docker compose up --build packages that binary into a local Docker image, starts a MySQL instance on port 3306, and deploys the demo databases using SchemaQuench. The launcher blocks until the completed service exits, which signals the databases are ready. Credentials live in Demos/MySQL/.env:

Setting Value
MySQL localhost:3306
User testuser
Password (see Demos/MySQL/.env)

Step 2: Cast with SchemaTongs

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": "MySQL",
    "Server": "localhost",
    "Port": "3306",
    "User": "testuser",
    "Password": "your-password-here",
    "Database": "Northwind"
  },
  "Product": {
    "Path": "./my-northwind",
    "Name": "Northwind"
  },
  "Template": {
    "Name": "Northwind"
  },
  "ShouldCast": {
    "Tables": true,
    "Functions": true,
    "Views": true,
    "Procedures": true,
    "TableTriggers": true,
    "Events": 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/
        Categories.json
        Customers.json
        Orders.json
        ... (13 tables)
      Views/
        Alphabetical_list_of_products.sql
        ...
      Procedures/
        CustOrderHist.sql
        ...
      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.

Step 3: Explore the Package

No GUI editor needed — the schema package is designed to read clearly in any editor or IDE. Open my-northwind/ in VS Code, JetBrains Rider, Visual Studio, or whatever your team uses. The .json-schemas/ folder gives you validation and autocomplete for every JSON file in the package automatically.

Click through Tables/Categories.json. You'll see the column definitions, the primary key, and any indexes. Open a stored procedure in Procedures/ and you see the full SQL definition ready to diff in a pull request. This is what schema review looks like when the files are designed for it: structured enough for tools, readable enough for humans, diff-friendly enough for code review.

Take a minute to click around. Every table, every view, every procedure in the Northwind database is here, structured and browsable. No server connection needed to explore.

The SchemaTongs Cycle

You just ran the SchemaTongs leg of the SchemaSmith workflow:

  1. Configure. You wrote a small tongs-extract.json pointing SchemaTongs at a live database with ShouldCast flags for the object types you wanted to capture.
  2. Cast. SchemaTongs connected to MySQL and extracted every enabled object type into a structured schema package.
  3. Explore. You opened the package in your editor and saw the entire database as readable, diffable, reviewable files.

No mysqldump gymnastics. No one-off export tools. No hand-authored DDL. You pointed SchemaTongs at a database and got a complete, version-control-ready package back. Every time.

Last reviewed May 2026 by the SchemaSmith Team.

What's Next

What's Next

You just extracted a live database into version-controlled files. The natural next step is deploying those files back through SchemaQuench — to a fresh database, to another environment, or to production. That's the deploy leg of the SchemaSmith cycle. DataTongs, the third tool, handles reference data and comes after.

Continuity note. This walkthrough extracted to ./my-northwind/ on purpose — so you could inspect fresh extraction output without clobbering the shipped ./demo/Northwind demo package. The SchemaQuench walkthrough uses ./demo/Northwind because that package bundles an Initialize template that bootstraps the empty Docker demo with a CREATE DATABASE script. SchemaSmith migrates schemas; it doesn't create databases itself — in production, the target database already exists as part of your infrastructure. The SchemaQuench walkthrough explains the bootstrap mechanism in detail.