A tenant is a customer organisation, with its own users and data. In a multi-tenant system they share the same code and servers, which keeps costs and effort low, but you must be certain one tenant can never see another’s data.
Three common patterns
| Pattern | How | Good for | Cost |
|---|---|---|---|
| Shared database, shared tables | Every row carries a tenant id; every query filters by it | Many small customers, fast start | Cheapest; a missed filter leaks data |
| Separate schema per tenant | One database, own set of tables for each tenant | Stronger separation, per-tenant changes | More to migrate and manage |
| Separate database per tenant | Each customer has its own database | Large customers, strict isolation, special requirements | Highest operations cost |
How to avoid leaking data
- Apply the tenant filter in one central place, not in every query by hand.
- Test explicitly that tenant A cannot reach tenant B’s records.
- Consider database features that enforce row-level separation.
- Include the tenant in logs and backups so you can reason about what belongs to whom.
Choosing for a start
For most new products the shared-table approach with strict, tested filtering is enough, and it can be moved to stronger isolation for particular customers later if they require it. Choosing a heavier design on day one usually buys complexity you do not yet need.