For a long time, our default answer to "how should we structure tenant data?" was Schema-Per-Tenant. And that wasn’t really because the other options were bad, but one had a cost problem that was hard to argue around.
Database-Per-Tenant gives you the cleanest isolation possible. Each tenant lives in a completely separate database.
No shared resources. No WHERE tenant_id = clause you have to trust across every query your team writes for the next five years + a compliance story that actually holds up when someone from legal asks you to explain it.
Honestly, I think we knew all that. Yet, we kept steering people away from it because the bill for running hundreds of idle database instances actually hurt.
Serverless Postgres changed that. When compute scales to zero on idle databases, the cost model for Database-Per-Tenant looks very different for products where most tenants aren't active simultaneously. The thing we kept citing as “dealbreaker” now depends heavily on your usage patterns.
Now, where are the patterns today?
Shared Tables with Row-Level Security is still a pretty solid starting point for many teams.
RLS enforcement has moved down to the database engine level. An improvement over relying on application code to get it right every time if you ask me. It's the cheapest option to operate and the simplest to reason about early on.
The tradeoff is that you're sharing resources, and noisy neighbor problems become real as you grow.
Schema-Per-Tenant remains that middle path most teams land on. One database instance, separate namespaces per tenant, and the operational side of managing migrations across many schemas has gotten meaningfully less painful as tooling has matured.
If you're not under serious compliance pressure and Database-Per-Tenant feels like overkill, this still makes sense as default.
Database-Per-Tenant is worth revisiting if you dismissed it because of cost (Me, I did).
But it's worth considering if you're building in AI or HealthTech spaces, where the consequences of tenant data mixing aren't just a customer support problem.
In AI products, how you isolate tenant data has direct implications for what the model learns and from whom. In HealthTech, compliance makes strong isolation a requirement, full stop.
We covered a lot of this in a video we made about multi-tenancy; how core patterns haven’t changed while cost assumptions have.
If you’re currently on shared schemas: was that a deliberate choice, or just what came first?
Top comments (0)