Shared Table vs Database per Tenant for Protected Data

Shared tables and databases per tenant solve different isolation problems. A shared table pools operations and reporting, but every application path must enforce tenant scope. A database per tenant creates a stronger infrastructure boundary, while adding migrations, backup, monitoring, and exit work. Choose the boundary your evidence and operating budget can actually sustain.

The right comparison is not “shared equals unsafe” or “dedicated equals compliant.” It is a review of who enforces access, what can bypass that enforcement, how recovery works, and what the contract requires. The current decision should be documented as an estimate and revisited when tenant count, data sensitivity, or insurer requirements change.

Isolation model and threat boundary

A shared table stores multiple tenants in one logical collection or table. The application supplies a tenant predicate on each operation, often using a server-resolved membership context. This can be efficient, but the database sees records rather than business authorization. A missed filter, broad aggregation, or administrative shortcut can cross the intended boundary.

With a database per tenant, the application selects a database connection or schema after resolving tenant membership. A wrong selection can still expose data, and privileged operators may still reach every database. The boundary is stronger only if credentials, connection routing, migrations, backups, logs, and support workflows preserve it.

The HHS Guidance on Risk Analysis supports an environment-specific assessment. Record which model is used, what it protects, which actors can bypass it, and what evidence demonstrates correct behavior. A contract or BAA may change duties, but it does not make either model safe by itself.

For a third option, compare pooled and silo tenant isolation. That model separates an entire workload or account, which may be more useful than choosing a database boundary in isolation.

Enforcement path and bypasses

Compare both models across the full lifecycle, not only the ordinary read path.

Concern	Shared table	Database per tenant
Normal request	Tenant predicate and membership check	Tenant connection selection and membership check
Reporting	Simple global reporting, high scope risk	Requires controlled fan-out or a separate aggregate store
Migrations	One schema path, broad blast radius	Repeated migrations, partial-failure handling
Backup	One copy can contain many tenants	Per-tenant copies and inventory work
Exit	Partitioned export and deletion proof	Connection, backup, and archive cleanup per tenant
Failure mode	Missed filter can cross tenants	Wrong routing or privileged access can cross databases

The eCFR administrative safeguards rule includes information access management and evaluation duties. Translate those duties into an access matrix. Include ordinary users, support, administrators, migrations, exports, queues, backup operators, and recovery operators.

Amazon Web Services’ DynamoDB Data Modeling Foundations reinforces an access-pattern-first approach. The specific service is not a prescription for this comparison. The transferable lesson is to enumerate reads, writes, lists, reports, and lifecycle actions before choosing a storage layout.

Operations, reporting, and tenant exit

Shared tables keep reporting and schema changes simple, but a global report needs an explicit purpose, authorization, and output policy. A database per tenant makes accidental cross-tenant reads less likely in ordinary code, yet a global report requires a controlled fan-out. That report path can become a new data store with its own retention and access surface.

Migration risk also changes shape. Shared tables have one migration, but a defective migration can affect every tenant. Per-tenant databases provide a smaller blast radius per run, but a failed rollout can leave tenants on different schema versions. The deployment must record progress, retries, rollback limits, and the operator who approved continuation.

Exit behavior is a design input, not a final ticket. For a shared table, export by tenant key, verify counts and hashes, revoke access, remove working copies, and prove that queued jobs and backups are handled. For per-tenant databases, include connection secrets, snapshots, replicas, logs, monitoring, and restore copies in the deletion inventory.

See tenant offboarding and deletion proof for a lifecycle checklist. Data return and destruction are not made complete by deleting one table or dropping one database.

Cost and decision evidence

Shared storage usually has a lower fixed operating cost at small scale. That is a planning assumption, not a compliance result. Per-tenant databases can add connection management, backups, monitoring, encryption keys, migration coordination, and support time. If a contract requires account or network isolation, those costs may be justified and should be quoted separately.

Estimate each model with the same workload. Count database operations, storage, backups, log retention, restore drills, migration hours, support hours, and exit work. Label any price as “as of 2026-08-15” and recalculate before commitment. Do not hide labor inside a cloud estimate.

For the shared model, reserve time for negative tests and query review. For the per-tenant model, reserve time for fleet health, migration orchestration, and tenant-level evidence. The cheaper invoice is not necessarily the cheaper control when one operator must keep the evidence current.

Reporting, analytics, and support tradeoffs

Shared tables make a global operational report easier to construct, but they also make scope mistakes easier to hide. A report must declare its purpose, actor, tenant set, and output destination before it runs. If the report includes more than the approved minimum, its result becomes a new data store with its own retention and deletion policy.

Per-tenant databases make a tenant report naturally narrow, but a portfolio report requires fan-out access or an aggregate store. Fan-out can create partial results, retry duplicates, and temporary files. An aggregate store can become the most sensitive service if it contains enough detail to reconstruct each tenant’s records.

Support has the same tradeoff. A shared support role can accidentally become a universal read path. Per-tenant connections can still be opened by a broad operator. Use ticket-bound, time-limited access in either model, record the tenant and reason, and review the result after the ticket closes.

Migration and exit questions

Before selecting a shared table, ask how one tenant will be exported without scanning every tenant into a temporary file. Before selecting separate databases, ask how a schema change will be rolled out, retried, and rolled back across a partially migrated fleet. Both answers belong in the architecture review.

Exit also changes the cost. A shared design needs partitioned export, queue drainage, credential revocation, and backup classification. A per-tenant design adds connection secrets, snapshots, replicas, monitoring objects, and archived logs. Price these steps before calling a model cheaper.

Record observed provider pricing and internal labor separately as of 2026-08-15. A storage invoice can be small while migration and evidence work dominate. If a contract or insurer requires a boundary, quote the required controls instead of using the shared model as a hidden subsidy.

Runnable proof tests

Use two synthetic tenants and run the same test suite against both models.

for each actor:
  attempt read, list, search, export, update, delete, and restore across tenants
  assert unauthorized records never appear
  assert failed access is logged without record content

for each migration:
  run against a copy
  assert schema version and tenant counts before and after
  force a partial failure
  verify retry and rollback behavior

for each exit:
  export one tenant
  revoke access
  inspect queues, logs, snapshots, and archives
  assert the approved deletion or retention result

Reject the decision if either model relies on a hidden administrator path, an untested report, or an unowned backup copy. Approve the narrow claim that the tests support, not a broader claim about the product.

Whichever model wins, bind it to an immutable tenant home-region decision before provisioning records, backups, or keys.

Frequently asked questions

Is a database per tenant automatically safer?

No. It creates a stronger potential boundary, but routing, credentials, support, backups, and reports can still cross tenants. Review the complete path and test a wrong-database request before making a stronger statement.

When does a shared table make sense?

It can make sense when tenant scope is resolved server-side, all operations are tested, reporting is controlled, and the residual risk is accepted. It is a poor fit when a contract requires dedicated infrastructure or the application cannot prove every access path.

What must be approved?

Approve the threat model, data-flow map, cost worksheet, negative tests, backup and restore plan, support model, and tenant exit procedure. Obtain separate legal review for contracts and regulatory duties.

References

• U.S. Department of Health and Human Services, Guidance on Risk Analysis, retrieved 2026-08-15: https://www.hhs.gov/hipaa/for-professionals/security/guidance/guidance-risk-analysis/index.html
• Electronic Code of Federal Regulations, 45 CFR 164.308 Administrative Safeguards, retrieved 2026-08-15: https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.308
• Amazon Web Services, DynamoDB Data Modeling Foundations, retrieved 2026-08-15: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/data-modeling-foundations.html