Building a SaaS product is fundamentally about an architectural question that you have to answer before the first line of business logic is written: how should different customers (tenants) share – or not share – the same infrastructure and data? If you choose the wrong model early on, the cost of changing is often enormous. This guide walks you through the established isolation models, how to implement robust data isolation with Row-Level Security, how to scale without one customer dragging everyone else down, and how to onboard new tenants in a controlled manner.
What multitenancy really is
Multitenancy means that one and the same application instance serves several customers, where each customer is onetenant. Tenants should never be able to see each other's data, but they share a code base and – depending on the model – they also share databases, schemas or entire environments. The opposite is single-tenant, where each customer gets their own, dedicated installation.
In practice, the question is rarely binary. AWS describes three well-known models in its SaaS Lens:pool(all tenants share resources),silo(dedicated resources per tenant) andbridge(a hybrid where some parts are shared and others are isolated). Most mature SaaS platforms land in some form of bridge.
Shared vs isolated: three database models
Pooled – shared database, shared schema
All tenants are in the same tables and each row is marked with onetenant_id. Isolation takes place logically via filtration. This is the most scalable and cost-effective model and the first choice for the vast majority of early stage B2B SaaS. The disadvantages: the weakest insulation, the greatest risk of "noisy neighbors" (a heavy tenant that affects others) and the most difficult to meet strict data residency requirements.
Silo – schema or database per tenant
Each tenant gets its own schedule or database. It provides strong isolation, eliminates noisy neighbors and simplifies regulatory compliance and data residency. The price is higher operational complexity: migrations must be run against hundreds or thousands of database objects, and when the number of tenants grows past about a thousand, object limits and migration times become a real problem.
Bridge – the hybrid
The most common reality: standard customers run pooled, while enterprise customers with compliance requirements or heavy loads get isolated environments. A new variant that has emerged is database-per-tenant with lightweight engines (for example SQLite-based edge databases) that sit between pooled schema and separate full-scale databases.
Build right from day one
The most important advice:make tenant_id a first-class column on every tenant-owned table - from the first migration, even if you start pooled and plan to go hybrid later. Adding tenant_id after the fact to a production database with real data is one of the most painful operations you can do.
Use oneUUIDas tenant_id. It avoids predictable sequences and makes data migration and merges easier.
Separate clearlytenant scopedtables (has tenant_id, must have RLS) fromglobal/sharedtables (missing tenant_id).
Design the API so that tenant context is derived from the authentication - never from a parameter the client can freely set.
Data Isolation with Row-Level Security
Trusting that every query is correctWHERE tenant_id = ...is an accident waiting to happen - a forgotten filter is enough. Row-Level Security (RLS) in PostgreSQL moves the isolation down to the database level, where it applies regardless of the code making the query. AWS elevates just this: RLS centralizes policy and removes the burden from individual developers.
Set tenant context securely
The recommended pattern is not to create a database user per tenant, but to set the tenant context at runtime. Inside a transaction:
SET LOCAL app.current_tenant = 'tenant-uuid'- withLOCALthe context is automatically reset when the transaction ends. It is crucial in pooled connections that are reused, otherwise the next request risks inheriting the wrong tenant.The RLS policy then compares the row's tenant_id against
current_setting('app.current_tenant').
If you build on Supabase, the tenant_id is retrieved from the user's JWT instead. Store it inapp_metadata, never in user_metadata – the latter can be changed by the end user himself, which opens an isolation gap. Aauth.jwt() -> 'app_metadata' ->> 'tenant_id'-based policy provides a clean and hard-to-manipulate rule.
Pitfalls to be aware of
Activate RLS onalltables with tenant data, and useFORCE ROW LEVEL SECURITYso that the table owner is also covered.
Views owned by a superuser role can bypass RLS entirely – a classic and dangerous miss.
Index on tenant_id (preferably composite, e.g.
(tenant_id, email)). If you see seq scans in the query plan, the index is probably missing.Add a CI control thataborts the build if a tenant table lacks RLS policy. It is the single most valuable protection mechanism against human error.
Scaling and noisy neighbors
The more that is shared, the greater the chance that one tenant's behavior will affect others. A single tenant running heavy reports can drag down response times for everyone in a pooled environment. Strategies to deal with this:
Sharding– distribute tenants across multiple databases or clusters, often with tenant_id as shard key.
Targeted isolation– move the heaviest or most sensitive tenants to the silo while the rest remain pooled. It is the bridge model in practice.
Per-tenant metering– measure resource consumption per tenant. It is required both to find noisy neighbors and to understand the unit economy. In 2026, this is basically standard, often supplemented with AI-powered monitoring.
Connection poolingwhich respects tenant context – combine with SET LOCAL as above.
Tenant onboarding
Onboarding is where the architecture choice meets reality. A new tenant must be able to be provisioned automatically and idempotent:
Create the tenant record, generate the tenant_id and associate it with the admin user's app_metadata/JWT claims.
In silo/bridge cases: provision schema or database and run baseline migrations. Automate this – manual provisioning doesn't scale.
Seed default data (roles, settings) in a transaction so that a half-finished tenant never becomes visible.
Verify isolation in an automated test immediately after provisioning: try reading another tenant's data and confirm that it is blocking.
The zero-trust mindset also applies internally: never assume that the application layer is filtering correctly. Let the database be the final, unyielding frontier.
Common mistakes to avoid
Postpone tenant_id "until we need it" - by then it's already too late and expensive.
Rely on application filtering alone without RLS as a safety net.
Put authorization data in fields that the end user can change.
Skip the silo migration strategy – a thousand schedules to be migrated at once will be a Friday you don't want.
No per-tenant-observability - then you only discover noisy neighbors when the customers get in touch.
What this means for your product
The right multitenancy model depends on your target group, your compliance requirements, expected tenant volume and how much variation there is between customers' loads. There is no universal answer – but there are right and wrong ways to keep the door open for future choices. At ZORC, we build SaaS architectures that start simple and pooled but are prepared to silo and bridge the day enterprise customers come knocking. Do you want an architecture that lasts from MVP to scale? Get in touch viacontactor do a quick needs analysis ithe quote calculator.
