Ask any SaaS founder what they would redo, and tenancy architecture appears in the first three answers. It is the decision that touches security, cost, performance, and every enterprise sales conversation you will ever have — and it is nearly impossible to change once real customers depend on it.
Having built or rescued more than thirty SaaS platforms, we have developed strong opinions about which tenancy decisions age well and which ones become the expensive rewrite of year three.
Start shared, but isolate by design
Shared infrastructure with row-level isolation is the right default for almost every early product — it keeps cost and operational load sane. The mistake is letting isolation live only in application code. Enforce tenant boundaries at the database layer from day one, so a missed filter in a query becomes an error, not a breach.
“Tenancy is not a technical detail. It is your future sales team’s negotiating position, written in SQL.”
Price metering into the schema
Whatever you meter — seats, usage, storage — model it explicitly from the start. Retrofitting usage tracking onto a schema that never expected it is one of the most common and most painful re-platforming triggers we see.
Leave the enterprise door open
You do not need single-tenant deployments in year one, but you need an architecture that will not laugh at the idea in year four. Keep configuration externalized, avoid hard-coded global state, and your first "we need our own instance" contract becomes a deployment exercise rather than a rewrite.
The best tenancy architecture is the one your team stops thinking about — invisible in daily work, ready when growth arrives, and boring in the best possible way.
Emperor Brains Engineering
Emperor Brains LLP
