The multi-tenancy decisions you can't make later
Most SaaS architecture decisions are reversible. A handful aren't — and they're usually made in week one, by accident.
SaaS Engineering · 6 min read
Most technical decisions in a SaaS product are reversible with enough engineering time. You can swap a framework, migrate a database, rewrite a service. A small number of decisions aren't reversible without a painful, customer-facing migration — and multi-tenancy strategy is at the top of that list.
The core question is simple to state and easy to underestimate: does every customer's data live in a shared schema with a tenant ID on every row, or does each customer get isolated storage? Shared schema is simpler to build and cheaper to run at small scale. Isolated storage is safer for compliance-sensitive customers and easier to reason about, but adds real operational overhead.
The mistake we see most often isn't picking the wrong model — it's not picking one deliberately at all. A team builds fast, tenant ID gets bolted onto a few tables, and by the time a customer asks about data isolation for a compliance audit, the answer requires a migration nobody budgeted for.
The same applies to plan limits and usage metering. If usage isn't tracked from day one, retrofitting billing means auditing months of historical data that was never captured with billing in mind. It's far cheaper to log usage events from the first paying customer than to reconstruct them later.
None of this needs to slow down an MVP. It needs about a day of deliberate design before the first migration is written — enough to make the decision on purpose, with the tradeoffs on the table, instead of by default.