Multi-Tenant Architecture
A software design where one application instance securely serves many customers (tenants), with each tenant's data isolated as strictly as if they had their own system.
Why it matters
Single-tenant deployments multiply cost and maintenance by customer count. Multi-tenancy matters because it makes modern SaaS economics possible, one codebase, one upgrade, many customers, but it concentrates the isolation problem: the architecture, not luck, must guarantee tenant A can never see tenant B.
How it works
Common patterns range from shared database with a tenant id on every row (enforced by row-level security), through schema-per-tenant, to database-per-tenant for extreme isolation. Requests carry verified tenant context from authentication; every query, cache, file path, and background job scopes to it. Billing, quotas, and configuration also key off the tenant.
A real-world example
A CRM serves hundreds of companies from one PostgreSQL cluster. Every table carries tenant_id, RLS policies enforce matching, and staff tooling uses separate audited paths. When one customer requests an export or deletion, it is a scoped operation, not an archaeology project.
Common mistakes
- ✗ Relying on application filters alone for isolation (one missed clause = cross-tenant leak)
- ✗ Leaking tenants through side channels: caches, logs, search indexes, file storage
- ✗ Sequential ids that let tenants infer each other's existence and scale
- ✗ No per-tenant export/delete capability, painful for both sales and compliance
Best practices
- ✓ Enforce isolation at the database with RLS in shared-schema designs
- ✓ Propagate tenant context from verified auth claims through every layer, including jobs
- ✓ Test cross-tenant access automatically in CI
- ✓ Design tenant export and deletion early; they unlock enterprise deals and legal compliance
Frequently asked questions
Is multi-tenancy less secure than single-tenant?
Done properly, isolation is enforced by the database and tested continuously, which is often stronger in practice than many separately-maintained single-tenant installs.
Which isolation pattern should a new SaaS pick?
Shared schema with RLS is the pragmatic default: cheapest to operate with database-enforced isolation. Escalate to schema- or database-per-tenant when contracts or regulation demand it.
What usually leaks first in bad multi-tenant systems?
Side channels: a cache keyed without tenant, a global search index, or filenames in shared storage. Isolation is a property of the whole system, not just the main tables.
Cortex and Vestiq are multi-tenant by construction: tenant ids on every row, RLS enforced, isolation tested, one platform serving many businesses safely.
Cortex's multi-tenant design →