Multi-tenancy

How Lerian Cloud and supported BYOC products isolate tenants, and how to choose dedicated or shared storage.

Multi-tenancy lets one deployment serve independent institution contexts (tenants) while keeping each request and its data within the authenticated tenant’s scope.

Lerian operates Lerian Cloud as a multi-tenant environment. In BYOC, multi-tenancy is available only for products and entitlements that support it. A BYOC Single-Tenant deployment is a separate configuration.

Tenant scoping and configuration are product-specific. Use the authentication and configuration guide for the product that you deploy. Do not assume an environment variable, JWT claim, or API behavior documented for one product applies to another.

Authentication and request scoping

---

Each product validates the caller’s identity and derives its tenant context according to that product’s authentication contract.

The platform does not define one universal tenantId claim or one universal tenant header for every product. A product integration must follow that product’s documented claim and routing behavior. Do not add a tenant identifier to a request unless that product explicitly requires it.

Multi-tenancy is an operational capability. It does not mean that every Lerian product has the same authentication middleware or configuration surface.

Storage isolation

---

• dedicated: a tenant receives a dedicated PostgreSQL database.
• shared: tenants share a PostgreSQL database and each receives a dedicated schema.

The database-versus-schema split is specific to PostgreSQL. Other datastores use their own mode-specific routing and provisioning rules. Do not infer PostgreSQL schema behavior for MongoDB or RabbitMQ.

Dimension	dedicated	shared
PostgreSQL isolation	Separate database per tenant.	Separate schema in a shared database.
Operational blast radius	A database-level incident is limited to that tenant’s database.	A database-level incident can affect tenants sharing the instance.
Cost and density	Higher isolation, more infrastructure per tenant.	Higher density, less infrastructure per tenant.
Restore design	Plan and test restores for the dedicated database.	Plan and test restores against the shared database and its schemas.

Choose the mode per service according to the service’s supported configuration, regulatory obligations, expected workload, and recovery requirements.

Moving a tenant between modes

---

Moving a tenant from shared to dedicated storage is an operator-planned migration. The platform has no generic automatic workflow for it. Validate the target product’s migration path, data-consistency requirements, maintenance window, backup/restore plan, and rollback procedure before changing a tenant’s storage mode.

The tenant identity can remain stable, but do not assume every product can move data between modes without an implementation-specific migration.

Operating each deployment model

---

Lerian Cloud

Lerian operates the multi-tenant infrastructure. Follow the product’s API and authentication documentation. Your token and the product’s routing contract determine the request scope.

BYOC Multi-Tenant

The operator configures the supported products, tenant services, storage mode, backing resources, and authentication. Treat each product’s configuration reference as authoritative.

BYOC Single-Tenant or local development

Multi-tenancy is not automatic. Authentication requirements depend on the product and environment. For Midaz, production and multi-tenant deployments require authentication. A permitted non-production single-tenant deployment can disable it.

Related pages

---

Use cases

How to choose dedicated or shared PostgreSQL isolation.

See examples

Deployment models

Compare Lerian Cloud, BYOC Single-Tenant, and supported BYOC Multi-Tenant configurations.

Compare models

Access Manager

Understand the supported authentication flows for the products you deploy.

Learn about authentication