Skip to content
PlaidCloud

You Can't Break Anything: Snapshots and Time Travel

~20 minutes · a snapshot, a look back in time, a change log

New to PlaidCloud and afraid of wrecking something? You can’t. Every time a table is written, the lakehouse keeps a snapshot of what it held — a consistent, point-in-time copy — and every change to a project is tracked for point-in-time recovery. The old states don’t go away when you overwrite them. This tutorial walks you through the three safety nets so you can stop tiptoeing and start trying things.

The whole idea in one line. Past states of your data are kept for you automatically. You don’t take a backup before experimenting — the backup already happened.

What You’ll Do

Section titled “What You’ll Do”
Safety net What it answers
Snapshots “What did this table look like before my last change?”
Time travel “Can I see the old data, not just know it exists?”
Project log “What happened in this project, and who did it?”

Prerequisites

Section titled “Prerequisites”
  • A PlaidCloud workspace (start a free trial if you don’t have one)
  • A project with at least one table in it — any table you’ve imported or built will do
  • Nothing to install; all three tools are built into Analyze

Step 1: Take a Snapshot on Purpose

Section titled “Step 1: Take a Snapshot on Purpose”

PlaidCloud snapshots a table on every write, but you can also capture one on demand — a good habit before anything you’d call risky (a big reload, a bulk edit).

  1. In the project Tables list, open the Snapshots panel from your table’s row. It lists the table’s snapshots newest first.
  2. Click Create Snapshot to capture the current data. Give it a name you’ll recognize later, like before I experiment.
  3. That named snapshot appears at the top of the list.

You now have a labeled point in time you can always come back to. With that in hand, go change the table — run a step against it, edit some rows, reload it. Whatever you do next, this snapshot is untouched.

Named snapshots are held. A snapshot you name with Create Snapshot or Hold is pinned and kept beyond the normal window — Release returns it to the ordinary lifecycle.

Naming and pinning depend on the table engine. Naming, pinning, and per-snapshot retention are available on lakehouse (StarRocks) tables. On Databend-backed tables, snapshots are still kept for the retention window, but individual snapshots can’t be named or pinned — so if you don’t see a name field, you aren’t doing it wrong.

Step 2: Read the Snapshot List

Section titled “Step 2: Read the Snapshot List”

The Snapshots panel is a timeline of the table’s life. Each row tells you what changed:

Column What it shows
When Date and time the snapshot was taken
Rows The table’s row count at that snapshot
Δ Rows Change in row count vs. the previous snapshot — so you can see what each write added or removed
Size Compressed storage size of the snapshot
Label A name, for snapshots you’ve named or pinned
Held A pin marker for snapshots kept beyond the normal window

Recent snapshots are retained for roughly 30 days, so there’s a real history here, not just your last save.

import900 rowscleanup850 rowsbefore I experiment850 rows · heldexperiment610 rows
Each write leaves a snapshot behind. The named one stays put no matter what you do after it.

Step 3: Travel Back and Look

Section titled “Step 3: Travel Back and Look”

Knowing the old data exists is reassuring. Seeing it is what makes you believe it. There are two ways to view a table as of an earlier snapshot — both open Table Explorer in a read-only historical view, with a banner showing which snapshot you’re on 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.

Open your before I experiment snapshot this way and you’re looking at the table exactly as it was before you touched it — the rows you changed, back the way they were.

This is a window, not an edit. The historical view is read-only. You’re looking at the past, not working in an editable copy — so browsing it can’t hurt anything either. When you’re satisfied the old data is really there, click Return to Current Data.

If you ever do want to bring an earlier state back into the live table, the Snapshots panel has Revert / Restore — it can either replace the table in place or restore the snapshot into a brand-new table, leaving the original alone. Reverting in place asks you to type the table name to confirm and captures a pre-revert safety snapshot first, so even undoing is undoable. You don’t need it for this tutorial; it’s enough to know the door is there. See Table Snapshots for the full walkthrough.

Step 4: See What Changed, Project-Wide

Section titled “Step 4: See What Changed, Project-Wide”

Snapshots cover one table. The project log covers everything — as actions happen in a project (running workflows, assigning members, and more), the log records them, consolidating every workflow’s log into one view.

  1. Open Analyze.
  2. Select Projects.
  3. Open the Log tab (the project log).
  4. To narrow the list, use the filter control next to the log messages and choose your criteria. To read one entry in full, right-click it and check the Log Message box for details.

Scroll back through it and you can retrace your own steps — the experiment you ran, when, and what it touched. Nothing you did is a mystery after the fact.

The project keeps its own history too. Beyond tables, all changes to a project — workflows, data editors, hierarchies, table structures, UDFs — are tracked and support point-in-time recovery, so you can recover from a mistake or copy an earlier state elsewhere for comparison. See Managing Projects.

So, Go Break Something

Section titled “So, Go Break Something”

You now have three ways to undo, review, or recover almost anything:

  • A snapshot you named before you started, plus one on every write.
  • Time travel to look at any of them, read-only, without committing to anything.
  • A project log that remembers what happened even if you don’t.

The fastest way to learn PlaidCloud is to try things. The safety nets are already under you — that was the whole point.

Where to Go Next

Section titled “Where to Go Next”