Multi-tenant SaaS (one SaaS platform serving many customers)

Salesforce sold the first commercial multi-tenant SaaS in 2000 as an alternative to on-premise CRM. Since then multi-tenant has become the economic standard for SaaS, while single-tenant has remained a niche for regulated industries. In the AI era the discussion is back: can multi-tenant safely host the models and data of different customers on a single infrastructure.

Three levels of isolation

Database-level isolation. All customers share one database, separated by a tenant_id on every record. The cheapest and most efficient option, but it carries a leakage risk in the event of code errors.

Schema-level isolation. Each customer has a separate schema in the same database. Better isolation, worse performance for cross-tenant analytics (which is usually not needed).

Instance-level isolation. Each customer has a separate server instance, a separate database and a separate vector store. This is single-tenant in its pure form. The most secure and most expensive option, economically inefficient below 100 customers.

In practice, mature SaaS use a hybrid: access controls at the application level, partitioning at the database level and monitoring at the infrastructure level.

Multi-tenant in the AI context

Three specific challenges that classic multi-tenant SaaS did not have.

Cross-tenant leakage of vector embeddings. If the embeddings of different customers live in the same vector index, a misconfigured retrieval can return customer A's documents in response to customer B's query. Mitigation: namespace isolation per tenant in the vector database.

Fine-tuned models per tenant. If a model is fine-tuned on customer A's data, it belongs to customer A. A multi-tenant model requires either a single base model plus prompt engineering plus RAG (separation at the context level), or per-tenant fine-tuned models (separation at the model level, which is more expensive).

Audit trail per tenant. Logs must be split by tenant. The AI Act requires separate logs for each customer using a high-risk system.

The choice for a Polish company

The multi-tenant versus single-tenant decision depends on three factors. First, regulation: the regulated financial sector (banks, insurers) often requires single-tenant with Polish hosting. Second, scale: below 50 customers multi-tenant gives no cost advantage. Third, the revenue model: enterprise sales with a high ACV justifies single-tenant.

Our two internal products, EXCORE and CBTL, are multi-tenant in 2026, with a database-level partition strategy plus a namespaced vector database.

We design the multi-tenant architecture for a client's custom platform as part of Custom platforms, applications, AI.