03.07 · Short
Modeling for Multi-Tenant Products
Add tenant boundaries, access controls, and partitioning strategies to a data model used by multiple customers.
Multi-tenant data models need explicit tenant ownership on tenant-scoped records, enforced tenant context on every access path, and a partitioning plan that matches isolation and operational needs. The core design choice is how far to share infrastructure while keeping customer data boundaries visible, testable, and hard to bypass.
What this lesson answers
- how should tenant_id be used in data models
- how to prevent cross tenant data access
- when should tenants use separate databases
Notes
In a multi-tenant product, the same application and data model serve multiple customers, so the model must make tenant ownership explicit. The most common starting point is adding a tenant identifier to every tenant-owned table and treating it as part of the logical key for reads, writes, joins, and uniqueness constraints. This prevents records from different customers from being accidentally mixed and makes the boundary visible in queries, indexes, and application code.
Common questions
- Should every table in a multi-tenant schema have a tenant identifier?
- Every table that stores customer-owned data should carry tenant ownership explicitly, usually through a consistent tenant identifier. Global reference tables are different and should be clearly marked as shared. The important point is that engineers can tell, from the model and queries, whether data is tenant-scoped or global.
- Where should tenant access control be enforced?
- Tenant access control should be enforced close to the data, not only in UI routes or client code. The application should derive tenant context from authenticated claims, then apply it through service boundaries, query construction, database policies, or views. The dangerous case is any query path that can run without a tenant predicate.
- Is one shared database enough for a multi-tenant product?
- A shared database with tenant-scoped rows is often the simplest and most efficient starting point. Separate schemas, databases, or clusters become useful when isolation, compliance, data residency, restore boundaries, or noisy-neighbour control matter more. Many products use a mixed model, isolating only the tenants that justify the extra operational cost.
Short definition: what is Modeling for Multi-Tenant Products?