Why multi tenancy is an architecture decision, not a feature
Every platform serving many clients on one installation must answer one fundamental question: how do you guarantee one client data is never visible to another. This is not something bolted on later, it is a decision that touches nearly every query, every report, and every file upload.
Mistakes at this layer differ from ordinary bugs. A functional bug breaks a feature; a tenant isolation bug leaks customer data, and that is an incident reputation rarely recovers from quickly.
Three common isolation patterns
- Separate database per tenant. Strongest isolation and easiest to explain to clients demanding guarantees. Operationally expensive: migrations run across many databases and monitoring gets complex at scale.
- Separate schema in one database. A middle compromise. Isolation stays clear, but very large schema counts can create performance issues on some engines.
- Shared tables with a tenant column. Most resource efficient and easiest to operate at scale, but most exposed to human error because every query must carry the tenant filter.
For most conversational CRMs the shared table pattern is the practical choice, provided filter enforcement is systematic rather than left to developer memory.
Layered defences worth installing
- Enforcement in the data access layer. Every query passes through one path that adds the tenant filter automatically, so a query without it cannot be written.
- Enforcement in middleware. Tenant identity comes from the authenticated session, never from a request parameter the client can manipulate.
- Enforcement in the database. Row level security gives a last layer that still holds when application code is wrong.
- Composite keys including the tenant on relations, making cross tenant references structurally impossible.
Where leaks actually happen
- Reports and aggregations, often written as custom queries outside the standard data access path.
- Export features, especially large exports running as background jobs.
- Global search, particularly when a separate search engine needs its own filtering.
- Media files. Guessable file links or links without an ownership check are a commonly missed leak because they bypass the database.
- Background jobs and queues, which run outside a user request and lose tenant identity unless it is carried explicitly.
- Inbound webhooks. Third party payloads must map to the right tenant using verified data, not values supplied by the sender.
Testing isolation systematically
- Integration tests with two tenants. Every test creates data on two tenants and asserts that requests as the first never return the second data.
- Negative tests on every endpoint. Try accessing another tenant resource identifier and ensure the response is consistent and does not reveal existence.
- Automated code checks flagging direct queries that bypass the standard data access path.
- Test background jobs separately, since this is the least covered area.
Performance and operational considerations
- Indexes should lead with the tenant column on large tables, because nearly every query filters by tenant first.
- Watch for giant tenants. One client far above average volume can affect others without resource limits.
- Apply per tenant rate limits, not only global ones.
- Plan per tenant deletion. When a client leaves you must be able to delete or export all their data completely and verifiably.
Frequently asked questions
Is a separate database always safer?
Easier to guarantee, not automatically safer. Misconfigured connections or overly broad credentials still leak. Discipline decides, not the pattern alone.
How do you handle clients demanding their own database?
Offer it as a separate deployment option at a different price. Forcing it for all tenants adds operational load without matching benefit.
Can you change pattern later?
Yes, but expensively. Moving from shared tables to separate databases is easier than the reverse, since data is already logically segmented.
What about data residency compliance?
If you serve countries with residency rules, plan per region deployment from the start. Adding it after hundreds of tenants exist is major work.
Next step
Audit the edge areas listed above in your own system, particularly exports, search, media files, and background jobs. Leaks are almost always there rather than in main queries. See the WhatsCRM Hub architecture approach on the product page.
