Multi-Tenancy

Multi-tenancy is a software architecture pattern where a single deployed instance of an application — one codebase, often one database — serves many separate customers ("tenants," typically companies or accounts), each with data that must be kept isolated from every other tenant, versus a single-tenant architecture where each customer gets their own fully separate deployment. Why it matters for AI/SaaS builders: nearly every B2B SaaS is multi-tenant by necessity — it's the only economically viable way to serve thousands of customers without provisioning and operating thousands of separate infrastructure stacks — and getting the isolation boundary wrong is one of the most consequential mistakes a growing SaaS can make, because a data-leak-across-tenants bug is often catastrophic (a support ticket becomes a security incident, an enterprise deal becomes a lawsuit) in a way most other bugs aren't. AI features add a new surface where this can go wrong specifically: a shared vector index, a shared prompt-caching layer, or a shared fine-tuned model can all accidentally leak one tenant's data into another tenant's results if isolation isn't enforced at every layer, not just the primary relational database. How it works: the three common patterns, in increasing order of isolation and operational cost, are: shared database, shared schema (every tenant's rows live in the same tables, distinguished only by a `tenant_id` column — cheapest to operate, but isolation depends entirely on every single query correctly filtering by tenant, with no structural backstop if a developer forgets); shared database, separate schema (each tenant gets their own Postgres schema within one database — stronger isolation, moderate operational cost); and separate database per tenant (strongest isolation, highest operational cost, typically reserved for large enterprise customers with strict compliance requirements). Row-level security (a Postgres feature) is increasingly used to add a database-enforced backstop to the shared-schema pattern, so even a query that forgets its `WHERE tenant_id = ?` clause still can't return another tenant's rows. Worked example: an AI CRM SaaS uses the shared-database, shared-schema pattern for its relational data (cheapest, works fine at their current scale) but layers row-level security policies on every table as a structural safety net, and additionally uses per-tenant namespaces in its vector database for AI-powered contact search — meaning a bug that omits a `tenant_id` filter in either the relational query or the vector query still can't leak data, because isolation is enforced at the infrastructure layer, not just in application code that a future engineer might get wrong.