Ask an engineer about multi-tenancy and you will hear about schemas, row-level security and noisy neighbours. All real. But the tenancy model quietly decides things far above the database: what you can charge for, who you can sell to, and what your worst incident looks like.
Tenancy is pricing
Shared-everything keeps your margins beautiful and your enterprise deals impossible: the security questionnaire will ask where the data lives, and "in the same table as everyone else’s, with a WHERE clause" is an answer that ends meetings. Dedicated-everything closes those deals and turns your ops team into a hosting company. Most products that survive end up hybrid: shared by default, isolated for whoever pays for the privilege. That is a pricing tier, and it should be designed by the same conversation that designs the rest of your pricing.
Tenancy is blast radius
The question is not whether you will ship a bad migration at 2am. The question is how many customers are inside it when you do. Tenant isolation is the difference between an incident report and an extinction event. We design the boundary for the failure mode first and the data model second.
Your tenancy model is your risk appetite, written in SQL.
If you are building a SaaS, decide the tenancy model with your commercial plan on the table. Retrofitting isolation into a shared-everything system is among the most expensive projects in software; we know, because we get hired to do it.
Written by the codemyx studio, the people who build the things these opinions come from.