Every B2B SaaS product eventually asks the same question: how do we isolate customer data without duplicating our entire application per tenant? After shipping 40+ production SaaS platforms, we've settled on a short list of decisions that determine whether multi-tenancy scales gracefully — or becomes a rewrite two years in.
1. Pick your isolation model before you write a line of code
Shared schema with a tenant_id column is the fastest to ship and the hardest to walk back later. Schema-per-tenant gives you stronger isolation and easier per-customer backups, at the cost of migration complexity once you're past a few hundred tenants. Database-per-tenant is rarely justified before enterprise-tier compliance demands it.
We default new products to shared schema with row-level security enforced at the database layer, not just the application layer — it's the difference between a bug and a breach.
"The tenant boundary should be enforced somewhere a single missed WHERE clause can't break it."
2. Billing and provisioning are coupled, whether you plan for it or not
Plan changes, seat additions, and usage-based add-ons all need to trigger provisioning changes in near real time. We treat the billing webhook as the source of truth for entitlements, syncing feature flags within seconds of a Stripe event rather than polling on a schedule.
3. Design your indexes for tenant-scoped queries from day one
Nearly every query in a multi-tenant app is scoped to a single tenant. Composite indexes leading with tenant_id keep query plans fast even as table sizes grow into the tens of millions of rows — retrofitting this after launch means downtime you can't easily schedule around live customers.
None of these decisions are reversible for free. Get the isolation model and indexing strategy right early, and the rest of your multi-tenant architecture stays boring — which is exactly what you want.