When we started Frizmo Platform, one of the first questions we had to answer was: "How do we separate data between clients?" That sounds elementary, but it's actually one of the most important decisions, because it shapes the architecture of the entire system — from database schema to production deployment.
In this article I'll walk through the three main approaches to multi-tenancy, their pros and cons, and when each works best. This is a summary of the research we did before choosing the model for Frizmo Platform.
Approach 1: Database per tenant
Each tenant (client) gets their own database. Isolation is complete — there's no way one tenant can accidentally see another's data.
When it works
- Enterprise clients with regulatory requirements (HIPAA, GDPR, banking)
- Tenants paying premium prices who expect isolated infrastructure
- Cases where each tenant has a significantly different schema
Downsides
- High costs — dozens of databases instead of one
- Complex deployment — migrations must be applied across all tenants
- Cross-tenant analytics is harder (platform-wide statistics)
- Connection pooling becomes non-trivial
Approach 2: Schema per tenant
One database, but each tenant has their own schema (in Postgres) or their own set of tables. Cheaper than database-per-tenant, but retains good isolation.
When it works
- Medium number of tenants (dozens to hundreds)
- Need for logical isolation without infrastructure overhead
- Cases where migrations apply equally to all, but data must be separated
Downsides
- At thousands of tenants Postgres starts feeling tired (max_connections, growing schema catalog)
- Cross-tenant queries require UNION ALL across all schemas
- Backup strategy becomes complex
Approach 3: Shared schema, tenant_id column
One database, one schema, every table has a tenant_id column. Isolation is logical at the application level and via Row-Level Security (RLS).
When it works
- SaaS with many tenants and a relatively simple schema
- B2C platforms where isolation matters but doesn't need to be enterprise-grade
- Budget constraints — this model is the cheapest of the three
- Frizmo Platform — this is exactly the approach we use
Downsides
- Isolation is "soft" — a bug in a WHERE clause can lead to data leak
- Requires discipline in code — every query must include tenant_id
- RLS policies in Postgres are a solution but must be configured carefully
What we chose for Frizmo Platform
For Frizmo Platform we chose the shared schema approach with mandatory tenant_id and RLS policies in Postgres. The decision was based on:
- Expected number of tenants — hundreds to thousands
- Schema is identical for all tenants
- Cost-efficiency — one database is significantly cheaper than hundreds
- Easy cross-tenant analytics for internal needs (platform statistics)
Conclusion
There's no universally correct answer. The choice depends on three factors: number of tenants, regulatory requirements and budget. For most SaaS products, shared schema with disciplined code is the right compromise. For enterprise clients with regulatory needs — database per tenant. Between them, schema-per-tenant covers niche cases.
A mistake we see often: starting with the wrong model due to incorrect assessment of future scale. Migration between models is possible, but it's significant work. Better to spend time on the decision now than to migrate later.