Multi-tenant SaaS architecture: the decisions that are expensive to reverse

Choose an isolation model deliberately

Most products should start with shared schema and row-level security enforced at the database, not in application code. Enforcement in the application means one forgotten WHERE clause is a data breach.

• Shared schema with row-level security: best economics, requires disciplined policy testing.
• Schema per tenant: easier per-tenant operations, migration cost grows with tenant count.
• Database per tenant: strongest isolation story for enterprise buyers, highest operational overhead.

Entitlement belongs in data

Plans, features, and limits should be rows, not conditionals. When pricing is code, every packaging experiment becomes an engineering project and sales stops asking. When it is configuration, a new tier ships the same day.

Meter from day one

Even on flat pricing, record usage per tenant and feature. It is the input to pricing decisions, capacity planning, support triage, and churn prediction, and it is nearly impossible to reconstruct historically.

Implement soft limits with in-product warnings before hard enforcement. Customers forgive a limit; they do not forgive a silent cut-off.

Prove isolation with tests

• Generate policy tests per table and fail the build on any cross-tenant read or write.
• Include the admin and support paths — impersonation features are where isolation usually leaks.
• Log every cross-tenant administrative access with actor and reason.