DB Snapshots

DB Snapshots turn a connected SQL database (or a folder of CSV files in Azure Blob storage) into a change timeline. Each capture records the state of the source's tables at a point in time, and each capture after the first produces a delta: the rows added, modified, and removed since the previous capture, with before and after values, plus any schema drift such as new columns. You configure snapshots on the Snapshots page by picking a live connection and a cadence; from then on the timeline shows how your reference data, master data, or operational tables evolve without you exporting anything.

The cadence decides how often a new capture runs: hourly, daily (the default, every 24 hours), weekly, or every N hours. Automatic captures can be paused without losing anything, and Capture snapshot runs one immediately. Incremental mode (the default) uses each table's update timestamp to fetch only changed rows and a key scan to catch deletions; tables without a usable timestamp fall back to a full scan, and Always full re-streams every table. A capture that is running can be stopped with Stop capture. Deleting the cadence stops scheduled captures but keeps every existing snapshot and delta; deleting the snapshot removes the captured history for that source.

Picking a delta and tracing a record

The capture strip at the top of a source doubles as the delta picker. Every capture on it stands for the delta that ended at that capture, measured against the capture before it, so clicking a point opens exactly that window. The delta view lists tables with their added, modified, and removed counts and drift flags, then pages the changed rows of one table with before and after values side by side. A delta that is still being computed is partial and its counts are a floor; the newest finished delta is marked as the last completed capture. A table that the scan cadence deferred this time is marked as not examined, so its zeros mean "not looked at" rather than "unchanged".

Record history answers the opposite question: given one table and one primary key, it lists every change the retained deltas recorded for that row, newest first, alongside the row's current values. Use it when a reviewer asks why a customer's credit limit or a supplier's bank details look different from last month. The same history is available to integrations and agents through the read-only /v1/db-snapshots API, which also exposes sources, timelines, deltas, and changed rows.

curl -s "https://api.talonic.com/v1/db-snapshots/sources/CONNECTION_ID/history?table=public.customers&pk=10442" \
  -H "Authorization: Bearer $TALONIC_API_KEY"

{
  "delta_id": "b4c6e8a0-1d3f-4b5c-9e7a-2f4d6b8c0e1a",
  "captured_at": "2026-08-29T02:00:04.221Z",
  "changed_at": "2026-08-28T16:42:17.000Z",
  "change_type": "modified",
  "before": { "id": 10442, "credit_limit": 50000 },
  "after": { "id": 10442, "credit_limit": 75000 }
}

Capture policy and external history

An optional capture policy (a JSON object in the snapshot settings) tunes how expensive sources are read. A change_feed lets tables covered by a feed the source already publishes skip both the scan and the deletion sweep: the platform re-reads only the keys the feed names. scan_policies sets, per table, how often it earns a real scan (every_captures, or max_age_hours since its last full scan), which bounds drift a feed cannot see. Without a policy every table is scanned on every capture. If a feed is unusable for a capture, that table falls back to a scan and the capture records why.

For Postgres sources that keep their own change history table, choose external history as the storage mode. The platform then stores no copy of the data at all: a sync job walks the source's history, writes a small marker snapshot and delta per burst of changes, and reads counts and before/after values from the history table whenever you open a delta or a record's history. Because the history records when each write happened, external-history changes carry an exact `changed_at` time. Platform captures only know that a row differed between two captures, so their changed_at is empty and captured_at is the best available time.

Snapshots pair well with the rest of the platform. Reference data that feeds matching and resolution often lives in exactly the databases you snapshot, so a delta tells you which master-data changes could explain a shift in match results between two runs. Schema drift flags warn you before a renamed or added column breaks a lookup, and record history gives reviewers evidence for when a value changed. Start with a daily cadence on the tables that matter most, add a capture policy once you know which tables are large or quiet, and switch Postgres sources that already keep an audit table to external history so the platform reads that history instead of copying the data.