Most clients don't need multi-tenant: single-tenant by default, architect the easy exit

The moment you smell a product underneath the contract, your brain reaches for multi-tenancy: one shared instance, a tenant_id on every table, everyone living together behind a column. It feels like the grown-up architecture. It’s usually premature, because the honest truth about most of my customers is that they will never share an instance with anyone, and I’d be paying for a wedding none of the guests showed up to.

So I do the unfashionable thing. Single-tenant by default. Each customer gets their own database. And the cleverness goes not into sharing the box, but into making sure the one client who eventually outgrows it can leave without a rewrite.

The tax you pay on every line

Multi-tenancy isn’t a setting you flip. It’s a discipline that touches every query you will ever write, forever.

• Every query grows a tenant clause. That tenant_id has to be on every read, every write, every join, every report. Forget it once on a list endpoint and one customer sees another customer’s orders. The shared-database model means a single missed WHERE is a data breach, not a bug.
• Every migration is a loaded gun. A schema change ships to everyone at once. There’s no rolling one customer forward to test, no holding a nervous client back a release. You move the whole estate together and hope the one with the weird data doesn’t fall over.
• Every “can you just” gets harder. A customer wants their own retention rule, their own export, a one-off backfill. In a shared database that’s a surgical operation around everyone else’s rows. In a separate database it’s a five-minute job you run against one box and walk away.

None of that tax buys you anything until you actually have customers crowded enough to share. And at the scale most B2B tools live at, a few dozen organizations, you never get there. You just pay.

Single-tenant, with a thin layer above

The shape I keep landing on: every customer is an isolated deployment with its own database, and a thin control layer sits above the estate to provision, monitor, and route. The control layer knows which customer maps to which instance and can stand up a new one from a template. It does not reach into their data. It’s a switchboard, not a landlord.

This gives you the thing multi-tenancy promised without the bill. Isolation is the default state of the universe, not a clause you have to remember to write. Customer A’s bad migration cannot touch Customer B. A noisy export does not starve anyone else’s queries. And when a client asks “where exactly does our data live,” the answer is a single database with their name on it, which sells better than you’d think in a low-trust market.

Architect for the customers you actually have, not the customers the pitch deck says you’ll have. The shared instance is a bet on crowding that most products never collect on.

Design the boundary so the exit is cheap

The catch is that single-tenant has its own failure mode: the day a client really does outgrow shared infrastructure, you don’t want that to be a rebuild either. So the one piece of foresight worth paying for upfront is the seam.

Keep the per-tenant boundary clean enough that lifting one customer into dedicated infrastructure means migrating exactly one database and repointing the control layer at it. No untangling their rows from a shared table. No careful DELETE that prays it caught every foreign key. You move a database, flip a route, done. That migration path is the thing I architect on day one, and it’s cheap precisely because the data was never entangled to begin with.

That’s the whole trade. Multi-tenancy front-loads complexity for a payoff most products never see. Single-tenant front-loads nothing and keeps one escape hatch oiled. When the rare client finally needs to move out, they take their database and leave, and everyone else never notices. Architect for the easy exit, and you never have to build the hard one.