Choose the boundary you can actually operate Shared tables, separate schemas, and separate databases can all support a multi tenant SaaS product. The choic...
Choose the boundary you can actually operate
Shared tables, separate schemas, and separate databases can all support a multi tenant SaaS product. The choice affects security, migration, backup, cost, reporting, and support work. A separate database sounds safer, but a shared privileged credential or careless export can still cross tenant boundaries.
In shared tables, tenant owned rows carry an enforceable tenant association. Application queries and policies must apply that scope, and database row security can add another boundary when supported and configured correctly. This model simplifies migrations and aggregated reporting, but a missed filter can be severe.
Separate databases can isolate data with credentials and backups if each tenant has distinct access. They multiply migrations, monitoring, connection management, and recovery operations. A hybrid model may reserve separate storage for high sensitivity customers while keeping standard tenants shared.
Compare concrete requirements
Document the largest tenant size, expected tenant count, data residency needs, support access, backup recovery objective, cross tenant analytics, and compliance commitments. Estimate how a schema migration reaches every tenant and how failed migrations are detected. Test tenant specific restore, not only whole platform restore.
Protect the rest of the system
Database separation does not automatically separate caches, object storage, queues, search indexes, or application logs. Include tenant context and authorization in each path. Background jobs must carry verified tenant context; a tenant ID in a message is not itself proof of authority.
Test isolation
For each design, attempt cross tenant reads and writes through listing, detail, export, files, and asynchronous work. For a row security design, test with the same database role and pooled connections used in production. For database per tenant, confirm credentials cannot open another tenant's database.
Also rehearse a single tenant restore. A shared backup may contain other customers' records; restoring the entire snapshot to recover one customer can overwrite unrelated live data. Document the extraction, verification, and authorization steps before an incident.
Conclusion
Pick the simplest boundary that meets the actual risk and operational requirements, then prove it under failure and recovery. See web and SaaS development for architecture support.
References