Local Snapshot destinations

The normal Local Snapshot path is intentionally simple: choose the case, review privacy, and let QueryDeck create the local destination.

Managed Docker — recommended

When Docker is available, QueryDeck can create an isolated PostgreSQL instance for the snapshot.

QueryDeck:

• selects a PostgreSQL image matching the source major version;
• uses a local loopback port;
• creates QueryDeck-owned container and volume resources;
• clones the source schema with PostgreSQL's native tools;
• writes the sanitized subset;
• saves the generated connection as SNAPSHOT · LOCAL.

If the required image is not already present, the first run can take longer while Docker downloads it.

Automatic local PostgreSQL

QueryDeck can also create a fresh querydeck_snapshot_* database on a saved writable PostgreSQL server running locally.

The local server must be marked Local or Development and must be compatible with the source PostgreSQL version and required extensions.

QueryDeck records ownership so the generated database can be safely removed later.

Existing PostgreSQL database — advanced

You can choose an existing saved Local or Development PostgreSQL connection.

For this path:

• the schema must already be compatible;
• every affected destination table must be empty;
• QueryDeck does not merge the snapshot into existing rows.

Schema cloning

Automatic destinations use PostgreSQL-native schema tooling rather than rebuilding the schema from QueryDeck's internal schema model.

This preserves PostgreSQL details that a generic database model could otherwise lose.

Supabase sources

Local Snapshot recognizes Supabase PostgreSQL sources and avoids offering an incompatible plain-PostgreSQL automatic destination when the source requires Supabase-specific runtime capabilities.

Next

• Manage created snapshots
• Review destination limitations