Database per tenant gives each customer a separate data-management boundary; a shared database pools tenant records behind enforced tenant-aware access. The best multi tenant SaaS architecture depends on isolation, recovery, scale and operating economics. Many B2B products benefit from a hybrid design, but only when tenant placement and lifecycle operations are automated and tested.

Key takeaways

• Application tenancy and database tenancy are separate decisions.
• A separate database does not automatically provide separate compute, credentials or complete security isolation.
• Shared data requires tenant-aware authorization across APIs, jobs, caches and reporting.
• Compare onboarding, schema upgrades, restore and offboarding alongside monthly database charges.

Two data-tenancy architecture diagrams

Microsoft’s multitenant data guidance evaluates sharing and isolation alongside tenant workload, lifecycle and operational requirements. Azure SQL’s tenancy pattern guide describes shared, database-per-tenant and hybrid options. Use the patterns to shortlist a design, not to assume one model fits every customer.

Database per tenant

Authenticated request → authorized tenant context
→ trusted tenant catalog → connection selection
├─ Tenant A → Database A
├─ Tenant B → Database B
└─ Tenant C → Database C

Fleet operations: provision, migrate, monitor, restore and retire
Compute or server resources may still be shared.

The catalog is a security-sensitive routing component. The application must derive the tenant from an authenticated and authorized context, then resolve an approved location. It must not accept an arbitrary database connection or tenant identifier as proof of entitlement.

Shared database

Authenticated request → authorized tenant context
→ tenant-scoped application operation → shared database
├─ Records for Tenant A
├─ Records for Tenant B
└─ Records for Tenant C

Tenant-aware keys, constraints, queries and permissions
Optional database RLS where supported and correctly configured

Pooling can simplify some fleet management, but it concentrates data and shared resource behavior. Treat missing tenant context as an error. Administrative and analytics paths need explicit cross-tenant authority rather than silently bypassing the ordinary rules.

Compare workload behavior, not just database count

For a product with many small customers, pooling can be attractive if access boundaries and shared performance are well managed. A large tenant with distinct recovery or placement needs can justify dedicated data resources. These are decision hypotheses to validate, not automatic rules based on tenant count.

Define the unit of isolation. A database can be separate while application processes, connection credentials, backups or server capacity remain shared. Write down the boundary promised commercially and the controls that actually enforce it.

Tenant isolation and row-level security

Enforce tenant authorization before selecting data. Validate membership and role permissions server-side. A browser route, header or query parameter can identify a requested tenant, but it cannot establish the caller’s right to use it.

For shared tables, carry tenant identity through keys, relationships and writes. Review whether uniqueness constraints and foreign keys must include the tenant dimension. A query filter cannot repair a relationship that permits one tenant’s record to reference another’s data.

Row-level security can provide an additional database enforcement layer where the chosen engine supports it. Validate session context, elevated roles and policy behavior, especially with connection pooling. Do not assume a single application filter or RLS policy covers raw SQL, background jobs, exports and support tooling automatically.

Scope caches, object storage paths, search indexes and messages as well as relational records. A correct SQL predicate does not prevent a cache key collision from returning another tenant’s response.

For database-per-tenant, restrict credentials and routing. A broadly privileged application identity coupled with an incorrect catalog mapping can still cross the intended boundary. Test both access denial and wrong-destination prevention.

Isolation tests to include

• A user from tenant A cannot access tenant B by changing an identifier.
• Missing or malformed tenant context fails closed.
• Background work retains its authorized tenant scope.
• Connection reuse does not retain the previous tenant’s context.
• Exports, search and support operations obey their access contract.
• Administrative cross-tenant access is explicit and auditable.

Migrations, recovery and tenant lifecycle

Database-per-tenant requires a fleet schema registry, controlled migration waves and clear handling of partial failure. Record which application versions can serve each schema version. A failed migration for one customer should not be hidden behind an overall deployment success badge.

For a shared database, test migration impact across tenant workload shapes. Large tables, concurrent writes and long transactions can change the release risk. Use compatible staged changes where old and new application versions coexist.

Restore is a business workflow, not only a backup feature. In a shared store, restoring the entire database can roll other tenants back unintentionally. A selective process may need a temporary restore, tenant-specific extraction, integrity checks and reconciliation with newer external actions.

A dedicated database can make the recovery boundary clearer, but related files, search indexes and messages may live elsewhere. Prove the complete tenant recovery objective, including dependencies and validation by the responsible owner.

Automate onboarding and offboarding. Provision or place data, register the catalog entry, configure access, verify readiness and record the result. Retirement should address retention, exports, credentials and related resources under the approved lifecycle policy.

For a tenant move, establish a source of authority, copy and reconcile data, manage writes during cutover, update routing and define a rollback boundary. Avoid uncontrolled simultaneous writes to both locations.

Billing, metering and SaaS pricing

Separate internal cost allocation from customer pricing. Database consumption is only part of the product cost: application compute, storage, network, support, observability, recovery and engineering effort also matter.

Capture tenant-attributable usage where appropriate and protect the metering path from duplication or loss. A shared database bill alone cannot tell finance how much each tenant consumed. A dedicated database bill may still exclude the tenant’s share of common services.

For an illustrative allocation method, distribute a common monthly platform cost by an agreed combination of base tenancy and measured consumption. Record that this is a management model, not exact physical attribution. Test whether it distorts decisions for large or unusually active tenants.

Do not advertise dedicated isolation simply because a commercial plan has a higher price. Make the technical boundary, support service and recovery commitment explicit. Verify current service pricing and commercial terms before promising margins or savings.

A selection matrix for B2B SaaS

A hybrid design needs one trusted placement model and consistent application authorization across pools. It is not a collection of manual customer exceptions. Keep schema policy, monitoring and migrations manageable as the estate grows.

Evaluate module boundaries through the .NET modular monolith guide and identity boundaries through the Azure access-path review.

Common questions

Design tenancy around customer and operating commitments

Bring tenant sizes, isolation requirements and recovery expectations. Discuss your .NET modernization roadmap to compare SaaS data boundaries and a sustainable tenant lifecycle.