SHOW SNAPSHOTS FOR

The SHOW SNAPSHOTS FOR statement lists a table's commit history — one row per snapshot, newest first, showing when each commit landed, who made it, what kind of operation it was, and how many records, files and bytes it added, deleted and left behind.

Each snapshot is a point the table can be read at with TIMESTAMP AS OF or VERSION AS OF, so this is the statement that tells you which points those are, and what each one changed. TIMESTAMP AS OF selects a snapshot by its committed_at; VERSION AS OF selects one directly by its snapshot_id, by a tag name from the tags column, or as PREVIOUS without looking either up. It answers from catalog metadata; no data files are read.

Syntax

sql

SHOW SNAPSHOTS FOR <table_name>;
SHOW ALL SNAPSHOTS FOR <table_name>;

Bare SHOW SNAPSHOTS is not supported — a commit history belongs to one table, and there is no session default workspace to list histories across. Name the table with the FOR form.

The ALL form adds the snapshots that have expired but not yet been purged — see Expired Snapshots below. It needs owner on the table, where the plain form needs only read access.

Parameters

<table_name> — fully qualified as <workspace>.<collection>.<table_name>.

Result Columns

Column	Description
`snapshot_id`	The snapshot's identifier
`committed_at`	When the commit landed, UTC
`is_current`	`true` for the snapshot a plain `SELECT` reads today; `false` for the rest. After a rollback this is not the newest row
`operation_type`	What the commit did, e.g. `append`, `overwrite`, `compact`
`author`	The identity that made the commit
`user_created`	`true` for a commit made by a user statement, `false` for one the engine made itself (a refresh, a compaction)
`sequence_number`	Monotonic write sequence number
`parent_snapshot_id`	The snapshot this one was committed on top of; `null` for the first
`schema_id`	The schema this snapshot was written against
`commit_message`	The commit's message, when one was recorded
`tags`	The tag names bound to this snapshot, as a list; empty for most rows. The current snapshot always carries `current`
`added_records` / `added_data_files` / `added_files_size_in_bytes`	What the commit added
`deleted_records` / `deleted_data_files` / `deleted_files_size_in_bytes`	What the commit removed
`total_records` / `total_data_files` / `total_files_size_in_bytes`	What the table held after the commit

SHOW ALL SNAPSHOTS FOR returns those columns and two more:

Column	Description
`expired_at`	When the snapshot was retired, UTC; `null` for a live one
`is_queryable`	`false` for an expired snapshot — the data behind it cannot be queried at all, by id, tag or timestamp

tags is also the answer to "why is this old snapshot still here". Snapshots are otherwise reclaimed on a schedule, and a tag is the one thing that holds one back — so a row far outside the usual history with a name in this column is being kept deliberately, and is being charged for. See CREATE TAG.

One name in that column is different: current is a virtual tag. It is not something anybody created and it holds nothing back from reclamation — it names whichever snapshot is the head right now, and it moves when the head moves. It is listed because it is a name you can write: VERSION AS OF current reads exactly like VERSION AS OF <any tag>. current and previous are reserved, so no real tag can take either name.

A counter the catalog never recorded is null, not 0. Zero would claim the commit added or deleted nothing; null says it was not written down. Older snapshots are the usual case.

Examples

List a Table's History

sql

SHOW SNAPSHOTS FOR my_workspace.sales.orders;

Find a Point to Read At

Look up the commit you want, then read the table as it was then — by timestamp, or directly by the snapshot_id this statement reports:

sql

SHOW SNAPSHOTS FOR my_workspace.sales.orders;

SELECT * FROM my_workspace.sales.orders
TIMESTAMP AS OF '2026-08-10 04:14:51';

SELECT * FROM my_workspace.sales.orders
VERSION AS OF 1755000000000;

If you only want the version of the data before the current one, VERSION AS OF PREVIOUS answers it without a lookup here at all — see VERSION AS OF.

SHOW SNAPSHOTS FOR is not a subquery source — it cannot be wrapped in FROM (...), filtered, or joined. Filter the returned rows client-side if you only want part of the history.

List Everything, Including What Has Expired

sql

SHOW ALL SNAPSHOTS FOR my_workspace.sales.orders;

Expired Snapshots

A snapshot the retention policy has retired is tombstoned, not deleted: the record stays for a recovery window (7 days) while its data files pass through the orphan quarantine and the bucket's own soft delete. SHOW SNAPSHOTS FOR does not list those rows, because they are not history you can read — and SHOW ALL SNAPSHOTS FOR is how you see them.

An expired row is a record of what is still restorable, not a version:

It cannot be read. VERSION AS OF <expired id> resolves to nothing, and a TIMESTAMP AS OF that would have landed on it no longer does. is_queryable is false and says so.
It cannot be rolled back to.
Restoring it is an operational task, not a query — it rebuilds the snapshot into a new dataset, and only while the files survive.
It disappears when the window closes. expired_at plus the recovery window is how long is left to act.

A tagged snapshot never appears here: a tag holds its snapshot from expiry indefinitely, which is what makes tags the answer to "why is this old snapshot still here".

Notes

SHOW ALL SNAPSHOTS FOR requires owner. What it adds is what the table is still holding in the restore window and how long is left to act on it — a question about the storage and its retention rather than about data the caller can already read, and acting on the answer is the owner's to do. It is gated exactly as SHOW MANIFEST FOR is; the plain form stays at read.
Requires read access. A snapshot row is commit metadata about a table you can already read — it exposes no file paths and no storage layout — so SHOW SNAPSHOTS FOR needs the same access as a SELECT against the table. This is deliberately weaker than SHOW MANIFEST FOR, which does expose storage layout and requires the owner role.
Catalog-backed tables only. The history is the catalog's commit log. A table on a store that keeps no commit log reports that it has no snapshot history, rather than reporting an empty one — the two are different answers.
A table with nothing committed returns no rows. That is an empty history, not an error.
Snapshots ahead of the current one are listed. A rollback moves the head backwards without deleting anything, so the snapshots it moved off stay in this history and stay readable by id — which is what makes a rollback reversible. They are not held from reclamation, though: once they age out they go, and the rollback can no longer be undone. A tag is what keeps one indefinitely.
Expired snapshots are not listed by the plain form. A snapshot retired by the retention policy leaves the history SHOW SNAPSHOTS FOR returns, even during the window in which it may still be recoverable: what that statement shows is the history you can read, not every commit ever made. SHOW ALL SNAPSHOTS FOR lists them, marked, for as long as the record survives.
Always returns the whole history. SHOW statements have no WHERE clause or column list, and the result is not a subquery source, so there is nothing to filter or project with at the source.
Free to run. No data files are read.