Database-per-tenant is the strongest form of multi-tenant isolation: each customer gets a completely separate database instance, with its own storage, compute, and index. No infrastructure is shared between tenants at the data layer.
This pattern is chosen when isolation requirements are strict. Because nothing is shared, there is no possibility of one tenant’s data leaking into another’s results, no risk of a noisy neighbour degrading performance, and each tenant can be backed up, scaled, migrated, or deleted entirely independently. It is often required in regulated industries or for large enterprise customers with security mandates.
The trade-off is operational cost and overhead. Running a separate database per tenant multiplies the number of instances to provision, monitor, patch, and pay for, which becomes impractical for applications with thousands of small tenants. It is best suited to deployments with a limited number of large, high-value tenants where the isolation justifies the expense — lighter patterns like namespaces or collections fit high-volume, small-tenant scenarios better.