핵심 요약
- Two models dominate inside one cluster: schema-per-tenant and shared schema with a tenant ID column. A cluster per tenant is the third, heaviest option.
- Schema-per-tenant buys stronger isolation at higher operational cost; shared schema is cheaper but makes every query responsible for tenant filtering.
- In TiDB, placement policies isolate a tenant’s storage and resource groups cap its compute, whichever model you choose.
- TiDB has no row-level security, so shared-schema isolation lives in application code or tenant-filtered views.
Picking the wrong tenant isolation model early is expensive to undo later: migrating thousands of live tenants from a shared schema to dedicated ones, or the reverse, means rewriting data access patterns under production load. This guide lays out the decision before you are stuck with it, using 티DB as the reference architecture.
What Are the Main Multi-Tenant Database Architecture Models?
Two models cover most multi-tenant systems running in a single cluster. In schema-per-tenant, each tenant gets a dedicated schema. In shared schema, all tenants share one set of tables and every row carries a tenant identifier. Schema-per-tenant gives stronger isolation at higher operational overhead; shared schema costs less to run but makes every query responsible for filtering by tenant.
Two clarifications keep the comparison honest. In TiDB, as in MySQL, a schema and a database are the same object, so schema-per-tenant means database-per-tenant. And a third model sits beyond both: a dedicated cluster per tenant, which gives the strongest isolation and the highest cost, and usually only makes sense for tenants whose contracts demand it.
Key Challenges of Multi-Tenant Environments
Building a multi-tenant architecture means balancing data isolation against resource sharing: designing for collective efficiency while keeping tenant data secure and latency low. Scaling to fit uneven tenant workloads without overprovisioning is a second challenge. High availability matters more than in a single-tenant system, since one failure can hit every tenant sharing that infrastructure at once.
Compliance requirements often force the decision more than technical preference does. Some industries and customer contracts require demonstrable data isolation at the infrastructure level, not just the application level, which rules out shared schema regardless of its lower operational cost. Find out which prospective tenants carry that requirement before you build, not after a large customer’s security review fails.
Schema-Per-Tenant vs Shared Schema at a Glance
| Attribute | Schema-Per-Tenant | Shared Schema |
|---|---|---|
| Data isolation | Separate database per tenant; privileges granted per database | Tenants share tables; isolation depends on tenant ID filtering |
| Tenant onboarding | Create a database and run the schema | Insert rows under a new tenant ID |
| Schema changes | Every DDL change runs once per tenant database | One DDL change covers every tenant |
| Storage isolation in TiDB | Placement policy per database | Placement policy per partition, if you partition by tenant ID |
| Compute isolation in TiDB | Resource group per tenant user | Resource group per session or statement |
| Compliance fit | Strong: isolation is visible in the schema | Weaker: isolation is enforced in code |
| Operational overhead | Grows with tenant count | Stays roughly flat as tenants grow |
How TiDB’s Architecture Supports Both Isolation Models
Neither model requires a different database, only a different configuration of the same architecture. Three TiDB features do the work, and it helps to know which kind of isolation each one provides.
Placement Policies Isolate Storage
Schema-per-tenant maps naturally onto Placement Rules in SQL. Label a set of TiKV nodes, define a policy that targets those labels, and attach it to a tenant’s database:
CREATE PLACEMENT POLICY tenant_dedicated CONSTRAINTS = "[+pool=dedicated]";
CREATE DATABASE tenant_acme PLACEMENT POLICY = tenant_dedicated;
Attach the policy when you create the database so its tables inherit it. Attaching a policy to an existing database sets the default for tables created afterward, not for tables already there.
That tenant’s data now lives on its own TiKV nodes, so its disk I/O stops competing with everyone else’s. What placement does not isolate is the SQL layer: every tenant’s queries still run through the same TiDB servers.
Resource Groups Cap Compute
That gap is what resource groups close. Each group gets a quota in Request Units, and a tenant that exhausts its quota queues instead of taking capacity from others. Resource groups work under either model: bind a group to a tenant’s database user in schema-per-tenant, or per session or statement when a shared-schema application pools connections under one user. The companion monitoring guide covers quotas and runaway query rules in depth.
Shared Schema Depends on Application Discipline
Shared schema has no physical boundary between tenants, and TiDB has no row-level security to draw one. TiDB privileges stop at the database, table, and (from v8.5.6) column level. Tenant isolation therefore lives in two places: every application query filters by tenant ID, and read-only access for a tenant can go through a view filtered to that tenant:
CREATE VIEW app.acme_orders AS SELECT * FROM app.orders WHERE tenant_id = 'acme';
GRANT SELECT ON app.acme_orders TO 'acme_reporting'@'%';
Key design matters too. Lead the primary key and composite indexes with tenant_id, so each tenant’s rows sit next to each other in TiKV’s key space. A tenant’s queries then scan a narrow key range instead of touching Regions across the whole table.
Onboarding Speed as a Deciding Test
Kimi uses a variation of the schema-per-tenant model at large scale, provisioning isolated databases for millions of AI-generated applications in about a second each. That only works because database creation runs inside Kimi’s automated pipeline, not as a manual step.
That speed requirement is a useful test for any product. If a new tenant needs to exist within seconds, the deployment pipeline has to create databases automatically from day one, not as a later add-on. Shared schema sidesteps the problem, since onboarding a tenant is just inserting rows under a new tenant ID, which is why it remains the more common starting point for products that have not yet proven a need for stricter isolation.
The Model You Choose Shapes Everything After
Schema-per-tenant and shared schema both run on the same TiDB architecture; the difference is configuration, not database choice. Once tenants are live, the work shifts to finding and containing noisy neighbors, which the monitoring guide covers.
Start a free TiDB Cloud Starter cluster to prototype both models before committing to one.
Multi-Tenant Database Architecture FAQs
Schema-Per-Tenant or Shared Schema: Which Should I Choose?
- Choose schema-per-tenant for strict compliance or security requirements.
- Choose shared schema for lower operational overhead at high tenant counts.
- Schema-per-tenant costs more in infrastructure and schema-change effort.
- Shared schema needs disciplined tenant filtering in every query.
Can I Migrate From Shared Schema to Schema-Per-Tenant Later?
- Yes, but each tenant you split out needs its own data migration.
- Plan for the possibility even if you start with shared schema.
- A hybrid is common: dedicated databases for large tenants only.
- You can apply placement policies incrementally as tenants move.
Does TiDB Support Row-Level Security?
- No. Privileges apply at cluster, database, table, and column level.
- Column-level privileges arrived in v8.5.6; rows have no equivalent.
- Filter by tenant ID in application queries.
- Grant read access through tenant-filtered views where a tenant needs direct access.
Can I Pin a Tenant’s Data to Dedicated Nodes in TiDB?
- Yes, with Placement Rules in SQL.
- Label TiKV nodes, create a policy targeting the label, and attach it to the tenant’s database.
- In shared schema, partition by tenant ID and attach policies per partition.
- Placement isolates storage; pair it with a resource group to cap compute.