Multi-Tenant SaaS Control Plane with Pool and Silo Tenant Isolation

The problem: every B2B SaaS rebuilds tenancy, usually badly

Almost every B2B SaaS, from a school management system to a clinic booking product or an HR tool, serves many customer organisations from one codebase. Early on, tenancy is a tenant_id column and a WHERE clause the developer hopes they never forget. Then a large customer arrives and asks for their data in a separate database, or one tenant's report query slows everyone down, or an auditor asks how the team guarantees one school cannot see another's records. The team realises tenancy is infrastructure, not a column.

AWS's SaaS guidance names the standard patterns: pool (shared resources, logical isolation), silo (dedicated resources per tenant) and bridge (a mix). Knowing the names is easy; building onboarding, isolation, metering and moving tenants between models is where small teams struggle.

What already exists and the gap

• AWS SaaS Lens and tenant isolation whitepaper describe pool, silo and bridge models in depth, as guidance rather than software.
• Nile offers PostgreSQL designed for multi-tenant SaaS, with tenant-aware features in its own managed service.
• Citus distributes PostgreSQL by tenant for scale, which solves sharding more than onboarding and isolation workflows.
• WorkOS and similar services handle enterprise login per tenant, not data isolation.

The gap is an open, self-hostable control plane that a small team can adopt on standard PostgreSQL: onboarding, tested isolation, metering and a pool-to-silo move as one coherent system.

What you build

• Control plane API: tenants, plans, limits and placement (pool or silo), with an admin UI.
• Provisioning workflows: durable, retryable workflows that create schemas or databases, run migrations, register routing and roll back cleanly on failure.
• Isolation: row-level security policies on every tenant table in pool mode, with the tenant set per transaction through PgBouncer-friendly settings; dedicated databases in silo mode.
• Tenant router: a small library for a sample application that maps each request to its tenant, its connection and its rate limit.
• Metering: per-tenant counters exported as metrics and rolled up into monthly usage.
• Tenant move: copy a tenant's rows to its new silo, stream changes until caught up, freeze writes briefly, switch routing, verify.

The technically interesting part

The tenant move is the showpiece. You must copy a live tenant's data while it keeps writing, capture and replay changes (logical replication filtered by tenant, or triggers writing to an outbox), bound the write freeze to seconds, and prove afterwards that nothing was lost or duplicated. Isolation is the second hard part: row-level security combined with connection pooling is easy to get subtly wrong, for example a tenant setting leaking between pooled sessions. Build an adversarial test suite that tries every leak you can think of, and present it to evaluators as evidence rather than a claim.

How to evaluate it

• Isolation tests: at least 30 automated cross-tenant access attempts (direct queries, pooled connection reuse, background jobs, missing tenant context), all of which must fail.
• Performance cost: latency and throughput of a sample workload with and without row-level security, at several tenant counts.
• Move downtime: write-unavailable time and total duration for tenants of different sizes, with integrity verified by counts and checksums.
• Onboarding time: seconds to provision a pool tenant and a silo tenant.
• Noisy neighbour experiment: show how one heavy tenant affects others in pool mode and how the move fixes it.

Suggested plan

1. Semester 1, weeks 1 to 4: study the models; build the control plane data model and API.
2. Weeks 5 to 9: pool mode with row-level security, the tenant router and the isolation test suite.
3. Weeks 10 to 14: silo provisioning with infrastructure as code and durable workflows.
4. Semester 2, weeks 1 to 4: metering and usage reports.
5. Weeks 5 to 10: the tenant move, integrity verification and experiments.
6. Weeks 11 to 14: evaluation, security review and write-up.

Path to a product

The first customer is an early B2B SaaS team, for example a school or clinic software company, that has just signed a customer asking for dedicated data storage. Release the control plane as open source and sell support, a hosted admin console, or implementation help. Software houses that build SaaS products for clients are a good channel because they meet the tenancy question on every project.

Scope warning

Do not build billing, authentication or a full admin portal for end customers. Do not support multiple database engines or multiple clouds. Skip sharding across many pool databases; one pool plus silos is enough to demonstrate every idea.

Learn what you need on Sefism

• System design roadmap : partitioning, isolation and consistency trade-offs.
• System design cheat sheet : quick reference for replication and data movement patterns.
• AWS Architecture Blog : SaaS architecture posts that discuss pool, silo and bridge models.
• Temporal Documentation : durable workflows for provisioning and tenant moves.
• PostgreSQL Documentation : row-level security and logical replication chapters.

Get help with this idea

The isolation test suite and the tenant move plan are where a mentor review saves the most time. A mentor can help you set the scope, pick a stack you can finish with, and design an evaluation your examiners will respect. The build is yours; the guidance is on scope, stack and evaluation. New here? Create a free account first.

• Discuss this idea with a mentor
• Send a query to Tauseef
• Book a 1:1 session