Home / Guides / Export or migrate one tenant

How to export or migrate one tenant out of a pooled database

A customer is churning and wants their data. Or you're moving your biggest account to a dedicated database. Or a data-portability request just landed. All three need the same thing: cleanly lifting one tenant — rows and files — out of a database shared by everyone else.

Exporting a single tenant sounds like a SELECT with a WHERE clause. In a pooled multi-tenant schema it isn't, for the same reason single-tenant restore isn't: one customer's data is a graph spanning foreign keys, join tables, denormalized columns, and object storage — not a single filterable table. Get the boundary wrong and you either leak another customer's rows into the export or hand over an incomplete dataset.

When you need a single-tenant export

• Customer offboarding — a churning account wants a complete copy of their data before you delete it.
• Pooled-to-dedicated migration — moving one large or regulated tenant onto its own database without re-architecting the whole product first.
• Data portability / DSAR — GDPR and CCPA give customers the right to receive their personal data in a portable form.
• Spin-off or acquisition — carving one customer's environment out to a separate system.

The tenant closure is the unit of export

The right export boundary is the tenant closure: the complete set of rows owned by one customer, plus the object-storage keys linked to them, plus enough shared-reference context to make the data usable — but never another tenant's private rows. TenantUndo resolves that closure from the schema graph, refusing to export until ambiguous relationships are pinned down with explicit rules.

Export, step by step

1. Resolve the graph

Introspect the schema read-only and classify every table. Ambiguous or inferred relationships are flagged and must be resolved before an unsafe export runs.

2. Extract the bundle

Extract the tenant closure to a portable bundle with a manifest and deterministic hashes. The same extract bundle that powers restore powers export — one mechanism, several jobs.

3. Include the files

Blob columns and S3-compatible object keys travel with the rows, so the export is the customer's whole footprint, not just their database records.

4. Verify integrity

Deterministic hashes let the recipient — or you — verify the bundle is complete and untampered, which matters for both migrations and formal portability requests.

Export and erase are two halves of offboarding

Offboarding usually means both: give the customer their data, then remove it. Run the export bundle first, then use the same tenant graph to plan and prove the erasure. One boundary, verified once, used for both.

Related: Restore a single tenant · Prove tenant deletion