Table Snapshots

Every time a table is written, PlaidCloud’s lakehouse keeps a snapshot of the table at that point — a consistent, point-in-time copy of the data. Snapshots let you look back at what a table contained earlier, recover from a bad load, and audit how a table changed over time. Recent snapshots are retained for roughly 30 days.

The Snapshots panel lets you browse that history, open any snapshot read-only in Table Explorer, and revert or restore the table to an earlier snapshot.

Every write records a point-in-time snapshot. Browse the history, open any snapshot read-only in Table Explorer, or revert the table to it — recent snapshots are kept ~30 days.

Opening the Snapshots Panel

In the project Tables list, click the snapshot/flashback button on a table’s row. The Snapshots panel opens, listing the table’s snapshots newest first:

• When — the date and time the snapshot was taken.
• Rows — the table’s row count at that snapshot.
• Δ Rows — the change in row count compared with the previous snapshot, so you can see what each write added or removed.
• Size — the compressed storage size of the snapshot.
• Label — a name, for snapshots you have named or pinned.
• Held — a pin marker for snapshots that are held (kept beyond the normal retention window).

Viewing the Data as of a Snapshot

There are two ways to view a table’s data at an earlier point in time. Both open Table Explorer in a read-only historical view with a banner showing which snapshot you’re viewing and a Return to Current Data button.

1. From the Snapshots panel — select a snapshot and click View at Snapshot.
2. From Table Explorer — use the As of dropdown in the toolbar. It lists the table’s recent snapshots; pick one to switch the view, or pick Current (live data) to return to live data.

Note

The historical view is read-only — it’s a window into the past, not an editable copy. Use Revert or Restore (below) if you want to bring old data back into a table.

Reverting or Restoring a Snapshot

Select a snapshot and click Revert / Restore. The dialog offers two choices:

• Revert this table in place (default) — replaces the table’s current data with the snapshot. Because this is destructive, you type the table’s name to confirm. Before the data is replaced, PlaidCloud automatically captures a pre-revert safety snapshot of the current state (on storage engines that support pinning), so you can always get back to where you were. On a Databend lakehouse, if the table’s columns have changed since the snapshot, an in-place revert is refused, naming the columns that changed — restore to a new table instead.
• Restore the snapshot to a new table — leaves the original table untouched and creates a new table in the project (you give it a name and folder) populated from the snapshot, with the same columns as the source. Through the AI assistant or MCP, a restore with no name given takes one based on the source table, for example Sales (restored 3f2a9c1d).

Caution

Reverting in place overwrites the table’s current data. The typed confirmation and the automatic pre-revert safety snapshot are there to protect you — read the dialog before confirming. Revert is blocked while the project is locked.

Note

Through the REST API or MCP, restore a snapshot in place by leaving the target table out, or naming the table itself. An in-place restore there gets the same protection as the dialog’s revert: a pre-revert safety snapshot where the storage engine supports one, and an audit record. To have it refused if the table has been written since you listed its snapshots, pass the newest snapshot you saw as expected_current_snapshot_id.

Note

If a restore to a new table fails — for example, because the snapshot has aged out — no new table is added to the project.

Naming, Pinning, and Retention

Snapshots age out of the retention window (about 30 days) automatically. To keep one longer:

• Create Snapshot takes a held snapshot of the current data on demand — useful before a risky reload (for example, “before Q2 reload”).
• Hold pins the selected snapshot; Release removes the hold and returns it to the normal lifecycle.

Caution

A hold keeps more than the one snapshot — it keeps the held snapshot and every snapshot written after it, so storage keeps growing until you release the hold. Replacing a table outright (an upsert, or an SCD-2 replace) starts a brand-new snapshot history, and any hold on the old one is lost with it.

Restoring every table in a project at once, through the REST API, restores each table to its most recent held snapshot and leaves tables with no hold as they are. A pre-revert safety snapshot doesn’t count as a hold. If any table can’t be restored, the others are still restored, and the request fails naming each table that wasn’t and why.

Note

Naming an on-demand snapshot is available on Lakehouse (StarRocks) tables. Holding and releasing a snapshot now works on Databend-backed tables too; snapshots there are still kept for the retention window even without a hold.

Auditing

In-place reverts, whether from the dialog, the REST API or an AI assistant, are recorded in the lakehouse audit log, including who performed the revert, when, the snapshot reverted to, and the safety snapshot that was kept — so table changes through this feature are traceable.