> ## Documentation Index
> Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt
> Use this file to discover all available pages before exploring further.

# Multi-tenancy use cases

> Choose dedicated or shared PostgreSQL isolation for a supported BYOC tenant service.

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, 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 the supported product can operate in `shared` mode and your operating model values density and lower per-tenant infrastructure cost.

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; and
4. post-migration checks for authentication, routing, and tenant data.

## Decision checklist

***

| Question                                                               | Favors `DATABASE` | Favors `SCHEMA` |
| :--------------------------------------------------------------------- | :---------------- | :-------------- |
| Does the tenant require a dedicated database boundary?                 | Yes               | No              |
| Can the tenant share a database-level maintenance and incident domain? | No                | Yes             |
| Is per-tenant infrastructure cost acceptable?                          | Yes               | No              |
| Does the product explicitly support the selected mode?                 | Required          | Required        |

## Related pages

***

<CardGroup cols={2}>
  <Card title="Multi-tenancy" icon="layer-group" href="/en/multi-tenancy" cta="See the overview">
    Product support, request scoping, and storage concepts.
  </Card>

  <Card title="Automatic provisioning" icon="wand-magic-sparkles" href="/en/multi-tenancy/auto-provisioning" cta="See provisioning">
    How tenant-service registrations provision supported resources.
  </Card>
</CardGroup>