In Shared Database Mode, all tenants live inside a single database. Each row has a tenant-id column and the platform filters every query to the current tenant's rows. It's the simplest, cheapest and most operations-friendly multi-tenant pattern.
How It Works
Every table that holds tenant data has a tenant_id column. The platform's data access layer automatically attaches WHERE tenant_id = ? to every query. The current tenant ID is set when the user signs in.
Pros
- Single backup, single restore.
- Single schema migration covers all tenants.
- Lowest infrastructure cost — one DB connection pool serves everyone.
- Cross-tenant analytics are easy (one query, no joins across DBs).
Cons
- Single point of failure: If one tenant fills the database with a runaway dataset, everyone slows down.
- Compliance: Some industries (healthcare, banking) require physical data separation.
- Risk of leakage: A single forgotten WHERE clause in custom code could expose another tenant's data.
- Per-tenant backups are awkward — restoring just Tenant B requires a row-level extract from a full backup.
Worked Examples
- SaaS with hundreds of small tenants: Shared DB is ideal — cost per tenant stays low; one schema; uniform feature releases.
- Internal multi-business-unit platform: Different teams as tenants; cross-team reporting is a common need; shared DB makes that trivial.
- Pre-launch / MVP: Start in shared mode while validating market. Migrate selected high-value tenants to separate later.
Tip: Audit every custom SQL query for an explicit tenant_id filter before deploying. The platform's ORM does this automatically, but raw SQL bypasses it. Use the “query audit” command-line tool to scan custom code.