Local Snapshot limitations

Local Snapshot is intentionally focused. It is not a full backup product, cross-database migration tool, or enterprise test-data-management platform.

V1 boundaries

• PostgreSQL → PostgreSQL only.
• The selected root table must have a declared primary key.
• Existing destinations must already have a compatible PostgreSQL schema.
• Every affected table in an existing destination must be empty.
• QueryDeck does not merge a snapshot into existing destination rows.
• Cyclic selected foreign-key graphs require a QueryDeck-managed Docker destination.
• Automatic destinations require compatible PostgreSQL tooling and required extensions.

Complex PostgreSQL behavior

QueryDeck checks schema compatibility and lets PostgreSQL enforce database-level semantics during the copy.

It does not attempt to reimplement every possible:

• CHECK expression;
• trigger;
• extension behavior;
• partial UNIQUE index;
• expression index.

If PostgreSQL rejects the copied dataset, the destination transaction rolls back instead of leaving a partial snapshot.

Cancellation

Cancellation is cooperative between database operations and batches.

A database call that is already blocking may return before cancellation is observed. QueryDeck still routes cancellation through cleanup and rollback before returning the workflow to an actionable state.

Privacy boundary

Local Snapshot sanitizes and de-identifies data according to the reviewed privacy profile. That is a technical safety feature, not a certification that the resulting dataset is legally anonymous.

Always apply your own organization's production-data policies.

What to use instead

Use a normal backup/restore workflow when you actually need a complete database copy.

Use Local Snapshot when the job is narrower:

reproduce this one real relational case locally, with privacy review, without cloning all of production.