Module 5 — Where to go next
You can declare a table, quench it into being, change it and preview the diff before it lands, and pull an existing database into source control. That’s the core SchemaSmith loop — the whole craft in miniature. But real databases don’t stay small. They multiply: many servers, many environments, a database per tenant, reference data that has to ride along. So before you go, here’s the map of where the road leads.
What you can do now
Section titled “What you can do now”Four modules in, you’ve got the fundamentals cold:
- Declare a table as a file and quench it into a real database — on SQL Server, PostgreSQL, or MySQL.
- Change the declaration, preview the exact diff with WhatIf, and watch SchemaSmith converge.
- Cast an existing, unmanaged database into a package you own with SchemaTongs.
Declare, quench, converge, cast. That loop is the same whether you’re shaping one table or ten thousand.
Where it goes next
Section titled “Where it goes next”The next course — Course 2 · Going Deeper — picks each of these up with hands-on labs. Here’s what’s in the next heat, and what each one’s for:
- Product — the blueprint (the jig) that guardrails what a deployment targets: the right server, the right databases, and nothing else. Details in the schema-packages reference.
- Templates — fan out to find every database (or schema) a definition applies to, so one quench run updates all of them at once. Same reference.
- Conditional deployment — one package that adapts per target: deploy an object on a newer engine, skip it on an older one, gate by edition or environment. That’s
ShouldApplyExpression, also in the schema-packages reference. - Script tokens — the adjustable dyes: one package, with values resolved per target, so dev, test, and prod share the same files without edits. See the script-tokens reference.
- Data delivery — ship the rows too, not just the structure: lookup tables, seed data, reference rows, cast in with DataTongs. See the DataTongs reference.
- Custom properties — hang your own metadata on the model and have the tools act on it. See the custom-properties reference.
You don’t need all of it on day one. Reach for each piece when the job calls for it — and the reference docs are there the moment you do.
Check yourself: Which capability would you reach for to deploy the same schema across many per-tenant schemas or databases at once?
Schema templates — multi-schema / multi-database fan-out. One quench run finds every database or schema the template applies to and converges them all.
You came in writing database changes by hand, one script at a time. You’re leaving with a loop: declare the shape you want, preview the change, and let the forge converge the metal — across one database or a fleet of them. That’s the foundation. Everything in the next course is just more leverage on the same idea.
Wherever you take it from here, my door’s open — forgebarrett@schemasmith.com. I read every one.
Next up: Course 2 · Going Deeper, where we put Product, templates, conditional deployment, tokens, and data delivery to work on real-world scale.
Until then, may your core loop hold and your fire stay hot for what’s next.
— Forge