Multi-tenancy is one of those decisions that is cheap to make on day one and impossible to undo on day five hundred.
Every SaaS product is multi-tenant; the question is whether you admit it on day one or five years in. We have shipped twenty-plus multi-tenant products in the last decade. The lessons cluster.
Pick your isolation model on day one
- Row-level for thousands of small tenants. Cheap, easy to operate, hard to migrate away from.
- Schema-per-tenant for hundreds of medium tenants. Easier per-tenant backups, more expensive cross-tenant analytics.
- Database-per-tenant for tens of large tenants with compliance requirements. Easy isolation, painful operational overhead.
Migrating between these later is a six-month engineering project. Pick deliberately.
Tenant context is a cross-cutting concern
Every query, every cache key, every log line, every background job needs the tenant ID. Solve it once with middleware, a request-scoped context, and a linter rule that fails if a query bypasses it.
Billing is part of the architecture
Plans, seats, feature flags, usage metering, trials, downgrades — these touch every part of the system. Design the billing layer in week one, not week fifty. Stripe, Paddle, and Lemon Squeezy can carry most teams.
Admin tooling pays for itself in 90 days
You will need: tenant impersonation, audit log search, refund processing, plan changes, data export. Build the admin app from sprint one. Customer success will use it more than your sales team uses Salesforce.
Audit log is not optional
For B2B SaaS, an audit log is the third question on every enterprise procurement form. Append-only, queryable, retained for 7 years. We default to a Postgres table partitioned by month plus an S3 archive after 13 months.
Background jobs need a tenant queue
One noisy tenant with a million webhooks should not starve the queue for everyone else. Per-tenant queues with weighted fair queuing solve this. Sidekiq Pro and SQS with multiple queues both work; the discipline is what matters.