QueryDeck Docs
Local Snapshots

Local Snapshot

Reproduce one real PostgreSQL case locally with its relational context and sanitized sensitive values.

For: developers debugging issues that only reproduce with real PostgreSQL data.

Local Snapshot turns one real database row into a focused local reproduction.

Find the row that triggers the bug, choose Bring to Local…, review the related-data plan and privacy decisions, then let QueryDeck create a local PostgreSQL snapshot you can inspect and modify without continuing to work against production.

What QueryDeck copies

Local Snapshot does not copy the whole database.

It starts from the selected row's complete primary key and follows the foreign-key relationships needed to keep the selected case coherent. The result is a bounded subset of related rows rather than a production dump.

The workflow is:

  1. Select a PostgreSQL row in Table Mode or Row Detail.
  2. Bring to Local… computes the related row set.
  3. Review privacy decisions for sensitive or ambiguous fields.
  4. Run provisions or validates a local PostgreSQL destination.
  5. QueryDeck copies the sanitized subset transactionally.
  6. Open Snapshot switches QueryDeck to the new local database.

Why use it

Local Snapshot is useful when:

  • a bug depends on a specific customer/order/session relationship;
  • fake seed data does not reproduce the same state;
  • you want realistic relational structure without cloning all production rows;
  • you need to debug freely against a local copy instead of keeping a production connection open.

Safety model

Production can be a source, never an automatic destination.

Source reads are performed through a read-only PostgreSQL transaction during execution. QueryDeck does not intentionally write an unsanitized intermediate dump to disk. Sensitive values are transformed before they are persisted in the destination.

QueryDeck calls this sanitization / de-identification, not legal anonymization or GDPR compliance.

Current scope

Local Snapshot V1 is PostgreSQL → PostgreSQL.

The selected root table must have a declared primary key. For the full list of boundaries, see Limitations.

Next