architecture

Multi-Tenancy in SaaS: Models, Trade-offs, and GDPR Implications

An architecture where a single software instance serves multiple customers (tenants), with logical or physical isolation of their data.

Multi-tenancy is the architectural property of a software system that serves multiple customers, or tenants, from a single shared deployment. It is the defining characteristic of SaaS: instead of deploying a separate instance of the application for each customer, one instance serves all of them, with logical or physical boundaries ensuring each customer sees only their own data and cannot access another's. Getting multi-tenancy right is one of the most consequential early architectural decisions in a SaaS product. The model you choose affects operational complexity, security surface area, compliance capabilities, enterprise sales potential, and how long your architecture can last before needing significant rework. For UK AI SaaS products, multi-tenancy intersects with GDPR in ways that require deliberate design. Under UK GDPR, each business customer whose users' personal data you process is a data controller, and you are their data processor. This means a Data Processing Agreement is required per customer, and the DPA must describe how tenant isolation is enforced technically. Enterprise customers in financial services and healthcare will ask specific questions about your multi-tenancy model during vendor security assessments: shared schema with row-level isolation versus schema-per-tenant versus database-per-tenant are three answers with very different implications for their risk evaluation. Starting with shared schema (the simplest model) is right for most AI MVPs, but designing the data model so that upgrading a customer to dedicated infrastructure is achievable without a full re-architecture is a valuable discipline. SpeedMVPs implements row-level tenant isolation with consistent tenant_id filtering, tenant-scoped vector database namespacing, and DPA-ready GDPR documentation as standard on every AI SaaS MVP.

The Three Multi-Tenancy Models

There are three principal approaches to multi-tenancy, differing in how much infrastructure is shared and how data isolation is enforced. The shared database, shared schema model puts all tenants in the same database and the same tables, distinguished by a tenant_id column in every row. This is the simplest model: one schema to manage, one set of migrations to run, and straightforward queries once the tenant_id filter is applied consistently. The shared database, separate schema model gives each tenant their own schema within the same database server. Tenant isolation is enforced at the schema level rather than the row level. Migrations need to be applied to each schema individually, which adds operational complexity but makes per-tenant operations (backup, deletion, cloning) much cleaner. The separate database model gives each tenant a completely isolated database. This provides the strongest isolation guarantee and is required by some enterprise customers and some regulatory frameworks. It comes with the highest operational complexity: provisioning new databases on signup, managing connection pools for many databases, and coordinating schema migrations across all customer databases.

Choosing the Right Model for an AI SaaS MVP

For the vast majority of AI SaaS MVPs, shared database with shared schema and row-level isolation is the correct starting point. The operational overhead of separate schemas or databases is significant and not justified until you have customers whose requirements specifically demand stronger isolation. The critical implementation discipline for shared schema multi-tenancy is ensuring that every single database query includes a tenant_id filter and that this filter is applied at a level where it cannot be accidentally omitted. In a Next.js application, this typically means wrapping your database client in a tenant-scoped helper that automatically appends the current tenant's ID to every query. Without this discipline, a bug in a single query can expose one tenant's data to another, which is a serious security and GDPR violation. Code review checklists that verify tenant_id filtering in every new query, combined with integration tests that verify cross-tenant isolation, are essential safeguards.

Multi-Tenancy for Vector Databases in AI Products

AI products using vector databases for semantic search or RAG pipelines face a specific multi-tenancy challenge. Vector databases like Pinecone, Weaviate, and pgvector do not naturally enforce row-level access control in the same way relational databases do. You need to implement tenant isolation explicitly. In Pinecone, namespaces provide logical partitioning: all of one tenant's embeddings go into their namespace, and searches are scoped to that namespace. In Weaviate, tenant isolation can be implemented using the built-in multi-tenancy feature (in recent versions) or through metadata filtering. In pgvector (PostgreSQL extension), row-level security policies can enforce tenant isolation at the database level. Failing to implement vector database multi-tenancy correctly means that a semantic search for one tenant could surface results from another tenant's documents, which is both a security failure and a GDPR violation if those documents contain personal data.

Enterprise Multi-Tenancy Requirements

As a SaaS product moves upmarket toward enterprise customers, multi-tenancy requirements become more demanding. Enterprise procurement teams, particularly in financial services, healthcare, and the public sector, will ask about data isolation as part of their security review. Common enterprise requirements include the ability to place their data in a specific geographic region (data residency for GDPR compliance), a dedicated database or schema that can be backed up and restored independently, the ability to bring their own encryption keys (BYOK) to encrypt their data at rest, and network isolation options such as private endpoints or VPC peering. These requirements do not need to be implemented at MVP stage, but designing your data model with clean tenant boundaries from the start means you can offer database-per-tenant as an enterprise tier without a data migration exercise when the time comes.

Multi-Tenancy and GDPR Article 28

Under UK GDPR and EU GDPR, when you process personal data on behalf of another organisation (your SaaS customer), you are a data processor and they are the data controller. Article 28 requires a Data Processing Agreement (DPA) to be in place between you and each customer for whom you process personal data. In a multi-tenant SaaS product, this means you need a DPA with every business customer. Your DPA must describe what personal data you process, for what purposes, with what security measures, and where it is stored. For UK products, the ICO has published standard contractual clauses that can form the basis of your DPA. For AI SaaS products, the DPA must also cover any LLM API calls that might process the customer's personal data, because those calls represent onward transfers to a sub-processor (OpenAI, Anthropic). You need your LLM provider's DPA in place and must disclose this sub-processing relationship in your own DPA.

Operational Considerations for Multi-Tenant AI SaaS

Running a multi-tenant AI SaaS requires operational disciplines that single-tenant applications do not. Tenant-aware logging is essential: every log line should include the tenant ID so that when investigating an issue, you can filter to the relevant tenant's activity. Tenant-aware monitoring allows you to detect when one tenant is consuming a disproportionate share of resources, either through legitimate high-volume usage or through a bug that is triggering excessive AI calls. Per-tenant rate limiting at the API level prevents runaway usage from impacting other tenants. For AI SaaS specifically, per-tenant LLM token usage tracking is important for cost attribution and for detecting anomalous usage. Tenant-scoped audit logs provide the compliance trail needed to respond to data subject access requests under GDPR and to FCA audit requirements for regulated products. SpeedMVPs builds all of these operational layers into multi-tenant AI SaaS products from day one.

Frequently Asked Questions

What is the difference between multi-tenancy and multi-instance?+

Multi-tenancy serves multiple customers from a single application instance with logical data isolation. Multi-instance deploys a separate application instance for each customer with physical isolation. Multi-instance is simpler to implement (no tenant_id needed anywhere) but operationally expensive: you manage N deployments, N databases, and N sets of infrastructure. Multi-tenancy is operationally efficient but requires disciplined implementation of isolation. Most SaaS products use multi-tenancy. Some enterprise software used multi-instance historically, and some regulated sectors require it.

How do I test that my multi-tenancy isolation is working correctly?+

Write integration tests that create two separate tenant accounts, populate each with test data, then verify that API calls authenticated as tenant A cannot access or retrieve data belonging to tenant B. Test every data access path: list endpoints, detail endpoints, search endpoints, and export functions. Test with both valid and manipulated authentication tokens. Run these tests in your CI/CD pipeline so that any code change that breaks tenant isolation fails the build before reaching production.

Does my SaaS need a DPA with every customer?+

If you process personal data on behalf of your business customers, yes. Under UK GDPR, if your customers upload or process personal data through your SaaS product, a Data Processing Agreement is required. For consumer-facing SaaS where individual users are the data subjects and there is no business customer in between, the requirement is different: your privacy policy and terms of service govern the direct relationship with the data subject. Most B2B SaaS products require DPAs with enterprise customers.

Can I offer dedicated databases to some enterprise customers while using shared databases for others?+

Yes, and this is a common tiering strategy. SME customers use the shared database tier (simpler, lower cost to operate). Enterprise customers who require dedicated infrastructure get a separate database provisioned for them, reflected in the enterprise contract. The key requirement is that your application layer can handle both models without different code paths, ideally by abstracting the tenant database connection so the application does not need to know which model is in use for a given tenant.

Does SpeedMVPs implement multi-tenancy correctly in AI SaaS products?+

Yes. Row-level tenant isolation with consistent tenant_id filtering, tenant-scoped vector database namespacing, per-tenant rate limiting, GDPR-compliant DPA workflows, and tenant-aware logging and monitoring are all part of our standard SaaS architecture. We design the data model for the multi-tenancy tier that fits your current customer profile and make it straightforward to upgrade customers to dedicated infrastructure as their requirements evolve. Get a free consultation at speedmvps.co.uk

Building a multi-tenant AI SaaS and want the architecture done correctly from the start? Get a free consultation at speedmvps.co.uk

Get a Free Quote