Published: September 10, 2026 · Last updated: September 10, 2026 · Author: Softix
Multi-tenant SaaS architecture for an early SMB product is less about buzzwords and more about one decision: how hard is it for Tenant A’s data, load, or restore to affect Tenant B? Softix’s answer for founders and product-engineering leads is Pool–Bridge–Silo—a data-tier path that starts with a shared-schema pool protected by tenant_id and PostgreSQL row-level security (RLS), upgrades to schema-per-tenant when you need a cleaner escape hatch, and moves to database-per-tenant only when compliance, blast radius, or customer contracts require it.
This post is the isolation-model layer for SaaS development and custom software development. It complements—not replaces—service-boundary choices in our modular monolith vs microservices guide and release contracts in API versioning for SMB SaaS. Softix will not invent tenant counts, “X% cheaper multi-tenancy,” or named customer outcomes. Measure your own query plans, restore drills, and support tickets.
Naming note (Softix vs AWS SaaS Lens)
The AWS Well-Architected SaaS Lens defines silo, pool, and bridge as ways resources can be dedicated, shared, or mixed across the stack. Softix reuses those words for the Postgres data tier founders ask about first:
Softix term Data-tier shape Closest SaaS Lens idea
Pool One schema; every tenant row stamped with tenant_id; RLS enforces isolation Pool isolation on a shared database
Bridge One database; schema-per-tenant (or strongly partitioned namespaces) Mixed / transitional footprint between shared and dedicated data
Silo Database-per-tenant (or stronger: account/VPC) Silo isolation for the data plane
AWS Bridge often means “some components pooled, some siloed.” Softix Bridge here means the common SMB upgrade step: schema-per-tenant inside a shared instance—still one ops surface, stronger physical separation than rows alone. Keep that distinction when you read vendor decks.
Plain English: what each model buys you
Pool — shared schema + tenant_id + RLS
One set of tables. Every tenant-owned row carries a non-null tenant_id (UUID or snowflake). The application sets tenant context per request; PostgreSQL row security policies filter rows so ordinary SELECT/INSERT/UPDATE/DELETE cannot see or write another tenant’s data—even if a developer forgets a WHERE clause.
Softix Pool defaults:
App role is not a superuser and does not have BYPASSRLS.
Enable RLS and, for the app role’s tables, prefer FORCE ROW LEVEL SECURITY so owners do not silently bypass policies during routine work (PostgreSQL RLS docs).
Set tenant context transaction-locally (for example set_config(‘app.tenant_id’, $1, true) inside BEGIN…COMMIT) so pooled connections cannot leak context across requests.
Policies use both USING and WITH CHECK so reads and writes are bracketed (CREATE POLICY).
Leading composite indexes include tenant_id so the policy predicate stays index-friendly.
Quotas and tenant-aware logs are product features, not afterthoughts (see below).
Pool fails when: connection pooling reuses session GUCs without reset; migrations run as a bypass role against live traffic without a rehearsed playbook; or “admin” tools query as table owner and skip policies.
Bridge — schema-per-tenant
Still one database instance, but each tenant gets a schema (tenant_acme, tenant_globex) or an equivalent namespace. Migrations may fan out; connection routing picks the schema after authentication. Isolation is stronger than a missing WHERE—a bug in one schema’s search_path is harder to turn into a cross-tenant dump—but you pay with migration orchestration and connection-map complexity.
Use Bridge when: a few large tenants create noisy-neighbor pain you cannot fix with quotas alone; you need per-tenant restore of a logical namespace without row surgery; or a buyer’s security questionnaire rejects “shared tables” but still accepts a shared instance.
Silo — database-per-tenant
Each tenant gets its own database (or cluster). Shared control plane still handles identity, onboarding, billing, and deploy—otherwise you have managed services, not SaaS (SaaS Lens silo isolation). Blast radius shrinks; ops cost and schema-drift risk rise. Softix treats Silo as a contract-driven upgrade, not a status symbol.
Comparison: Pool vs Bridge vs Silo
Dimension Pool (shared schema + RLS) Bridge (schema-per-tenant) Silo (DB-per-tenant)
Isolation strength Logical (policy + app context) Stronger logical/physical namespace Strongest data-plane boundary
Cost / density Highest density Medium Lowest density
Migration story One migration path Fan-out / rolling per schema Fan-out per database
Noisy neighbor Highest risk—needs quotas Reduced per schema Lowest (until shared compute)
Restore granularity Point-in-time of shared DB + careful extract Schema dump / logical restore Whole DB restore
Compliance narrative “Shared tables, enforced RLS” “Dedicated schema” “Dedicated database”
Softix default for early SMB Start here Upgrade path Enterprise / regulated exceptions
AWS pool isolation guidance is explicit: sharing does not relax isolation requirements—it increases the chance of cross-tenant access and noisy-neighbor effects. Softix agrees: Pool is valid only with enforced policies, quotas, and observable tenant context.
Softix Pool–Bridge–Silo operating model
1) Pool — ship isolation you can prove
Do this before second paying tenant:
Stamp every tenant-owned table with tenant_id NOT NULL.
Enable RLS + policies; negative tests that attempt cross-tenant reads must fail under the production app role.
Reject requests without a resolved tenant (middleware fails closed).
Add quotas: API rate, storage, concurrent jobs, export size—keyed by tenant. Softix does not publish universal numbers; set limits from your worst-week load plus headroom.
Emit tenant-aware logs: every request log line and error carries tenant_id (and preferably request_id). Metrics and traces should allow “show me only Acme’s p95.”
Keep the product a modular monolith until tenancy—not vanity—forces extract. Isolation and service count are different axes.
2) Bridge — upgrade when Pool’s failure modes are real
Upgrade signals (any two is usually enough):
One tenant’s batch jobs move shared p95 beyond SLO after quotas are tuned.
A prospect’s security review requires schema-level separation you cannot honestly describe with RLS alone.
You need per-tenant logical restore drills that are too painful on shared rows.
Schema experiments for a premium tier must not risk the shared catalog.
Bridge is not “microservices.” You can Bridge the database while still shipping one web app deployable. Pin API contracts with your Path–Pin–Sunset discipline so tenant routing changes do not break clients.
3) Silo — upgrade when the contract is the product
Silo when: regulated data residency, contractual “dedicated database,” ransomware blast-radius requirements, or a tenant whose backup/restore SLA cannot share a PITR window. Surround siloed data planes with shared identity, metering, and ops—or you are running N products (SaaS Lens).
Softix default order: Pool → Bridge → Silo. Skipping to Silo on day one is allowed for a single enterprise design partner; do not pretend it is the cheapest path to ten paying SMBs.
Quotas and tenant-aware observability (non-optional in Pool)
Isolation without quotas is a polite invitation to noisy neighbors. Softix minimum:
Control What to enforce Failure if skipped
Request rate Per-tenant token bucket at edge or API gateway One crawler starves others
Storage Soft + hard caps on blobs / row growth Shared disk surprises
Export / report jobs Concurrent job limits + max row scan Analytical queries as DoS
Logs tenant_id on every line Blind incident response
Metrics Tenant-tagged latency & error rate You only see “the app is slow”
Tenant tags in logs are not “nice for support”—they are how you prove isolation incidents are contained.
When-to-upgrade path (one page)
Weeks 0–4: Pool with RLS, negative tests, quotas v0, tenant_id on logs.
First SLO breach from one tenant: tighten quotas; only then consider Bridge for that tier.
Enterprise questionnaire fails “shared tables”: offer Bridge (schema) or Silo (database) as a paid tier, not a free rewrite of everyone.
Regulated design win: Silo that tenant; keep others on Pool/Bridge; one control plane.
Never: “We’ll add RLS later.” Later is how cross-tenant bugs become launch-day stories.
Softix checklist (copy into the eng handbook)
Tenancy model written: Pool / Bridge / Silo (and which tenants may differ)
App DB role cannot BYPASSRLS; policies cover ALL DML with USING + WITH CHECK
Tenant context set transaction-locally; pooler reset verified
Negative tests for cross-tenant read/write in CI
Quotas on rate, storage, heavy jobs
Logs/metrics/traces carry tenant_id
Onboarding creates tenant record + (if Bridge/Silo) namespace/DB provisioning
Restore drill documented per model
Upgrade triggers listed (noisy neighbor, compliance, restore SLA)
Adjacent concerns linked: API sunset policy, monolith boundary rules—not conflated with tenancy
FAQ
Is shared-schema multi-tenancy “real” multi-tenancy?
Yes. Pool is the classic multi-tenant data model. Isolation strength depends on RLS, roles, and operational discipline—not on marketing that says “dedicated.”
Does Softix Bridge match AWS Bridge exactly?
No. Softix Bridge is schema-per-tenant (data-tier upgrade). AWS Bridge is a mixed pool/silo footprint across components. Both acknowledge that pure pool or pure silo is not the only honest architecture.
Should we Silo because a competitor markets “dedicated database”?
Only if the contract, compliance, or restore story requires it. Softix prices Silo as the expensive isolation tier, not the default for every SMB signup.
How does this relate to Neon branching or preview DBs?
Preview branching is an environment lifecycle concern (temporary databases for PRs). Tenancy isolation is a production data-plane concern. Do not confuse ephemeral branches with Pool–Bridge–Silo.
Can we run Pool in a modular monolith?
Yes—and Softix usually recommends that until extract criteria are met. Tenancy policies live in the data access path; microservice count does not create isolation by itself.
Softix CTA
If you are choosing multi-tenant SaaS architecture for a US SMB product—Pool with RLS, Bridge schemas, or Silo databases—Softix can scope the isolation model, quotas, and tenant-aware ops alongside SaaS development, custom software, and web app development. Let’s talk with your current schema and one failed (or feared) cross-tenant scenario—we will not invent benchmarks you have not measured.
Before you commit runway, pressure-test Build vs Buy vs Customize with Softix’s SMB software TCO calculator.
Primary sources
AWS SaaS Lens — Silo, Pool, and Bridge Models
AWS SaaS Lens — Pool isolation
AWS SaaS Lens — Silo isolation
PostgreSQL — Row Security Policies
PostgreSQL — CREATE POLICY
Share
