[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"glossary-multi-tenancy::en":3,"gloss-cluster-multi-tenancy::en":20,"gloss-next-multi-tenancy::en":9},{"slug":4,"category":5,"name":6,"definition":7,"meta_desc":8,"faq":9,"schema_markup":9,"related":10},"multi-tenancy","data-infra","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\u002FSaaS 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.","Multi-tenancy is an architecture where a single application instance serves multiple customers (\"tenants\") while keeping each tenant's data isolated.",null,[11,14,17],{"slug":12,"name":13},"namespace","Namespace",{"slug":15,"name":16},"postgresql","PostgreSQL",{"slug":18,"name":19},"sharding","Sharding",[21,25,28,31,34,38,41,44,47,50,54,57],{"slug":22,"category":5,"name":23,"updated_at":24},"acid","ACID","2026-08-24T02:46:37+00:00",{"slug":26,"category":5,"name":27,"updated_at":24},"ann-search","ANN Search",{"slug":29,"category":5,"name":30,"updated_at":24},"backpressure","Backpressure",{"slug":32,"category":5,"name":33,"updated_at":24},"batch-processing","Batch Processing",{"slug":35,"category":5,"name":36,"updated_at":37},"bm25","BM25","2026-08-24T02:46:38+00:00",{"slug":39,"category":5,"name":40,"updated_at":24},"cache","Cache",{"slug":42,"category":5,"name":43,"updated_at":24},"cap-theorem","CAP Theorem",{"slug":45,"category":5,"name":46,"updated_at":24},"change-data-capture","Change Data Capture (CDC)",{"slug":48,"category":5,"name":49,"updated_at":24},"chroma","Chroma",{"slug":51,"category":5,"name":52,"updated_at":53},"chunk-overlap","Chunk Overlap","2026-08-24T03:30:02+00:00",{"slug":55,"category":5,"name":56,"updated_at":24},"columnar-storage","Columnar Storage",{"slug":58,"category":5,"name":59,"updated_at":24},"connection-pooling","Connection Pooling"]