Discover a fleet from its catalog

One tenant per database sounded clean when you had three. Now you’ve got three hundred, they’re sharded across a handful of servers, and every schema change is three hundred deploys you have to not fumble. Miss one and that tenant drifts. Script them by hand and you’re one fat-fingered loop away from touching the wrong database.

Hey folks. I’m Forge Barrett, master of the Content Forge here at SchemaSmith.

Courses 1 through 6 got your schema forged, versioned, and deployed like an operator. This track is about scale — running that same schema across a fleet of databases where the interesting question isn’t “is the schema right?” but “how do I reach every tenant, exactly once, and know I did?”

You don’t deploy a database — you deploy a roster

Here’s the shift. On a single database, you point the tool at a name and quench. On a fleet, naming the databases in your package is a trap: the list is out of date the moment a customer signs up. So you stop naming them.

Instead, the package declares how to find the fleet, and hands the tool one job: reconcile every database that answers. You deploy a roster, not a database. The roster is discovered fresh on every run — so the package never changes when the fleet does.

The catalog already knows who’s in the fleet

You don’t need a spreadsheet of tenant databases. Every engine keeps a live catalog of its databases — sys.databases, pg_database, information_schema.schemata — and your fleet is just the ones that match a convention. A template’s discovery query reads that catalog and returns the roster. No side table to maintain, no list to keep in sync. The source of truth is the server itself.

Onboarding is a data change, not a release

Follow the catalog and something nice falls out. A new tenant’s database gets created — and the next run finds it and forges the schema in. No package edit. No new release. No pull request. Adding a tenant became a CREATE DATABASE, and the fleet-wide deploy you already run picks it up.

That’s the whole mental shift: canonical package, discovered roster, reconcile-what-answers. Get it, and a fleet of three hundred is no harder to run than a fleet of three.

The track ahead

Four modules, each one a layer on the last:

Module 1 · Database-per-tenant fan-out — the spine. One Shop package, discovered across every tenant database, forged in a single run. Onboard a new tenant without touching the package.
Module 2 · Steering the roster — when the catalog shouldn’t own the list. Hand the roster to your deployment config instead, and narrow a run to a subset.
Module 3 · Provisioning at onboarding — let SchemaSmith stand the tenant database up itself, as part of the run.
Module 4 · Operating the fleet safely — preview a thousand-database run before you pull the trigger, tune how hard it hits, and keep going when one tenant misbehaves.

Start with Module 1, because discovery is the habit the rest build on.

New to SchemaSmith? Get the CLI on your PATH first — Course 1, Module 1 walks the install. Come back when schemaquench --version answers.

Check yourself: Why does a fleet package declare how to *find* its databases instead of naming them?

Because a named list is stale the instant the fleet changes — a new tenant signs up and the package is already wrong. A discovery query reads the engine’s live catalog on every run, so the roster is always current and the package never has to change when the fleet does. Onboarding becomes a CREATE DATABASE, not a package edit.

A good smith doesn’t forge each blade to a different pattern. He sets one true mold and runs the whole batch through it — every piece comes out the same, whether it’s three or three hundred. That’s a fleet: one canonical shape, struck into every tenant, proven the same across all of them.

Running a fleet you’ve never actually counted? Email me at forgebarrett@schemasmith.com — tell me how many tenant databases you’ve got and how you deploy to them today, and I’ll tell you where the by-hand cracks are hiding.

Next up: Course 7 · Module 1 — Database-per-tenant fan-out, where one package forges the Shop schema across a whole fleet in a single run — and onboards a new tenant without a single edit.

Until then, may your mold stay true, your roster stay current, and every tenant come off the fire the same.

— Forge

Mark this lesson complete