Skip to main content
Choose an isolation mode per tenant service after you have confirmed that the product supports multi-tenancy. In Tenant Manager registrations, the values are dedicated and shared. This page uses the corresponding PostgreSQL concepts DATABASE and SCHEMA.

​
Choose DATABASE (dedicated) when isolation dominates

Use a dedicated PostgreSQL database per tenant when the tenant needs a strong infrastructure boundary. The same applies when the tenant needs independent database maintenance windows, or a recovery plan designed around a dedicated database. Typical examples include a highly regulated institution, a high-volume tenant, or a tenant whose workload must not share a PostgreSQL instance with other tenants. This choice increases infrastructure and operational cost, so validate the product’s connection, backup, and migration design first.

​
Choose SCHEMA (shared) when density dominates

Use a dedicated schema per tenant in a shared PostgreSQL database when your operating model values density and lower per-tenant infrastructure cost. The supported product must also be able to operate in shared mode. A database-level incident or maintenance action can affect tenants on the shared instance. Plan capacity, backups, recovery, and maintenance around that shared blast radius.

​
Treat migration as a product operation

Do not rely on a generic automatic promotion from SCHEMA to DATABASE. Moving a tenant to dedicated storage requires an operator-planned migration that the target product supports. Before changing a registration, establish:
  1. the target product’s supported migration procedure
  2. a tested backup, consistency, and rollback plan
  3. a maintenance window and communication plan
  4. post-migration checks for authentication, routing, and tenant data.

​
Decision checklist

Multi-tenancy

Product support, request scoping, and storage concepts.

Automatic provisioning

How tenant-service registrations provision supported resources.