Multi-Tenant SaaS Architecture: 7 Decisions Every Founder Must Make Early

How should I architect a multi-tenant SaaS application?

You architect it by making 7 decisions before you write code, in this order: tenant isolation model, authentication and tenant context, billing and metering, data residency, customization layer, migration path, and compliance posture. The first decision — Pool vs Bridge vs Silo — is the most consequential because it sets the cost ceiling, the compliance posture, and the migration tax for every subsequent change. Pool is one database with a tenant_id column on every table; cheap, low isolation. Bridge is one database with a schema per tenant; mid cost, mid isolation. Silo is a dedicated database per tenant; expensive, high isolation. Most SaaS products start in Pool, graduate larger paying tenants to Bridge, and reserve Silo for enterprise compliance customers. The migration between models is the part founders underestimate. Design the migration before tenant #1, not at tenant #100.

Tenant isolation — the foundational choice

Pool gives you the lowest cost and the easiest cross-tenant analytics. It's where free and starter tiers live. Bridge gives you per-tenant schema isolation, which matters when you start having tenants who need slightly different schemas (custom fields, different column types). Silo gives you full physical isolation — separate database, separate backups, separate keys. It's where enterprise tenants with regulatory requirements live. Most SaaS products mix all three. Free users in Pool. Pro users in Bridge. Enterprise customers in Silo. Each tier pays the cost of its isolation. The mistake we see: starting in Silo because "isolation feels safer". You burn through the runway maintaining 50 individual databases for tenants who would have been happy in Pool, and you've created an operational nightmare you can't migrate out of.

“”

Auth, billing, and customization decisions

Auth (Decision 2): Pick subdomain-based tenant context (acme.app.com) for B2B SaaS, or JWT-embedded tenant_id for B2C. Subdomain wins for enterprise customers because they can configure SSO at the IDP level. JWT wins for products with personal accounts and team upgrades. Don't do both — pick one. Billing (Decision 3): Stripe Billing handles per-seat and usage-based pricing well; metering is the hard part and we typically wire it through a usage-aggregation table that runs nightly. Customization (Decision 5): Build a JSON config table for tenant settings. Never use feature flags as customization (flags are for releases, configs are for tenants). Never branch code for customer-specific features — that's a rebuild waiting to happen. We've productionized 12+ multi-tenant SaaS products at SaaS Development — the customization layer is where most rebuilds start.

How do tenants graduate between isolation models?

The lifecycle: tenant signs up free → lands in Pool. Tenant upgrades to Pro → automated migration to Bridge (new schema, data copy, validation, routing update). Tenant signs an enterprise contract with compliance requirements → migration to Silo (provision new DB, full data export, separate backup pipeline). Each migration is a project, not a button click. Pool → Bridge is typically 1–3 hours per tenant. Bridge → Silo is 1–3 days per tenant. The migration path needs to be designed from day one — every table needs a tenant_id, no foreign keys cross tenants, no shared mutable state, and your operations team needs runbooks for the routing flip. For tenants approaching the regulated-data threshold, the Silo migration also brings in cloud infrastructure decisions about region, backup retention, and per-tenant audit trails.