Product details
What the list shows, and the four-step wizard that creates one
The mockup above is the run history — every snapshot this project has ever fired. Each row pairs a Snapshot run with the source → target it ran against, the COMPLETED pill, the date stamp, the elapsed time, and a delete action. Below, the cards walk through the list and each step of the 'Run snapshot' wizard, including the destructive-action gate that asks the operator to retype the target connection identifier before anything drops.
The list at the top
The mockup above is the snapshot run history — every one-shot baseline this project has ever fired. Each row leads with the run name (Snapshot · plan), packs the copy-able run hash next to it, names the masked source → target databases in mono, drops the green COMPLETED pill, and stamps a start time and elapsed duration on the right. The trash button is the only action, because once a snapshot is done there isn't much else to do with it — it lives as a receipt, not a thing to keep editing.
What a Snapshot actually does
A Snapshot is the destructive baseline. Cupcake reads the source's DDL for every in-scope table, drops the matching tables on the target, recreates them from the source's exact column types and indexes, and bulk-copies every row across. The result is a new source-to-target baseline; consistency depends on the selected source and snapshot behavior — exactly the 'before' a CDC stream needs to start tailing changes against. Run a Snapshot once at the start of a replication path, then turn on CDC and let it carry the target forward from there.
Step 1 — Endpoints
The wizard opens on a screen that asks where the data is coming from and where it's going. SOURCE and TARGET drop zones accept Connection chips dragged from the pool underneath — the same Connection rows the Connections page surfaces — and a hint reminds the operator they can drag onto an in-use slot to use the same connection on both sides. Once both slots are filled, the Database pickers come alive: the source side lists the databases that connection can see, the target side lists the targets it can write to, and the names don't have to match (orders → orders_dw is the example the helper text cites).
Step 2 — Scope
Two big tiles: All tables (snapshot every table in the source database — the default and the right answer most of the time) or Subset (pick specific tables — useful for staged rollouts or spot-tests when only a handful of tables are in scope for the move). Subset opens a checkbox list of every table the source exposes; All tables skips that and lets the wizard move to Confirm.
Step 3 — Confirm (the typed-gate step)
This is the page that keeps Snapshots from being a foot-gun. An amber DESTRUCTIVE pill sits at the top right of the card. An Operation summary names the source / target / scope / mode — including the exact count of target tables that are about to be dropped — and a warning card spells out exactly what is about to happen: 'This will drop N target tables in target_connection/target_database. Cupcake drops each target table, recreates it from the source DDL, then copies rows. Any data currently in target_database inside the snapshot scope is destroyed. This action is irreversible without a separate backup.' Continue is gated behind a confirmation field that asks the operator to retype the target connection identifier verbatim. Mistypes don't drop databases on this page.
Step 4 — Launch
Final read-out of the choices, then a single Run button that fires the job and drops the operator back on the list. The new row joins the table with a fresh timestamp; once it flips from RUNNING to COMPLETED, the target is ready for CDC.
Why Snapshots come before CDC
CDC is a tailing engine — it picks up new changes and applies them. It can't backfill what was already there before it started. Without a Snapshot first, a CDC stream attached to an empty target will only ever contain the changes that happened after the stream started; everything older stays missing. Run a Snapshot, then turn on CDC, and the target ends up with both the historical baseline and the live feed of new changes. It's the order that turns 'we copy data' into 'the target is the source.'
The honest baseline
Cupcake can't pretend the target matches the source — so it doesn't. A Snapshot drops the target tables, recreates them from the source DDL exactly, and bulk-copies the rows. The target ends up in a known-good state that the team can prove to themselves, and CDC has something concrete to start replicating against.
A destructive action with a typed gate
Step 3 of the wizard puts an amber DESTRUCTIVE pill on the screen, names every table that will be dropped, and asks the operator to retype the target connection identifier into a confirmation field before Continue lights up. Misclicks don't drop databases on this page.
A receipt for every baseline
Every Snapshot run lands in the history with a copy-able hash, the masked source → target flow, a COMPLETED pill, a start time, and an elapsed duration. Five clean runs in the screenshot equal five proven baselines — the answer to 'when did we last fully resync this target?' is a glance, not an archeology project.
