Multi-tenant architecture in 2026: what we learned building platforms for thousands of users

Multi-tenancy sounds simple: multiple customers, one application. In practice, it's one of the hardest problems in SaaS.

We've made the mistakes, fixed them under production load, and arrived at a set of patterns that work. Here's what we know.

Data isolation: your most important decision

At some point, every multi-tenant system has a conversation about data isolation:

• Row-level: All tenants share tables, filtered by tenant_id
• Schema-level: Separate schemas per tenant in the same database
• Database-level: Separate database per tenant

Row-level is the default. It works fine until you're doing compliance work for enterprise customers who want to know their data is physically separated.

We use row-level with Convex for most applications, but we've built schema-level for enterprise customers who need stronger guarantees.

Custom domains

Every enterprise customer wants their own domain. This sounds easy. It isn't.

SSL certificate management, DNS propagation, multi-origin routing — it requires real infrastructure work. Vercel makes this easier with their Platforms product.

Billing per tenant

Metered billing tied to actual usage is the correct model. The hard part is instrumenting usage accurately — counting API calls, storage, active users.

We instrument everything. Even if we're not billing on it today, we want the data.

What breaks at scale

1. Database queries that work fast for 10 tenants fail at 10,000
2. Background jobs that process one tenant at a time become bottlenecks
3. Notifications per-user become thousands of concurrent operations

Building for scale doesn't mean premature optimization. It means making architectural choices that don't need to be reversed later.