Park Work and Switch Database State

Role: Developer · Screens: Data timeline → Take Snapshot, then Data → Restore · Time: a few minutes per switch

This page is the clicks. For the story, read Switch Between Schema States for Urgent Tasks. Restore details (target picker, overwrite) match Restore a tagged snapshot.

Tag so Restore can see both states

Restore lists the latest snapshot per data item and tag combination. If every backup uses the same tags, you will only see the newest version there. Park and switch needs different tag values for each state you might return to.

Example for one app database:

work=baseline — schema before the long feature
work=feature-wip — parked in-progress work
Keep a stable tag such as app=quemsi on all of them if you filter that way too

Set those tags when you Take Snapshot from the data timeline (they are filled in on Execute Flow). They then show on the timeline and on Restore. You cannot retag a version from Restore.

Before you start

This database is already a data item on Data. If not, follow Take a tagged snapshot.
A work=baseline (or equivalent) snapshot exists from before the long-running change. If it does not, take one now—before you park anything else. Clicks: Snapshot before a schema change.
The database you overwrite is a writable MySQL, PostgreSQL, SQL Server, or Oracle datasource. MongoDB restore is not on Restore.
Each restore overwrites that database (drop or clear, then load).

Steps

1

Park the current database

Do this before you restore something else, or the in-progress schema is gone.

Open Data, open this data item, click Take Snapshot, pick the backup flow, click Take Snapshot again.
Set tags, for example app=quemsi and work=feature-wip. Add a short description of where you stopped. Click Execute Flow.
On the timeline, confirm the new version and its tags.

2

Switch to the other state

Open Data → Restore (or /app/restore). Filter Tag work, Value baseline (and app if you use it). Pick the card, choose the same database you develop on, confirm overwrite, wait for the execution to succeed.

Full restore clicks: Restore a tagged snapshot.

3

Do the urgent work

Fix, test, and ship against that restored schema. If that work might matter later, park it too with its own value, for example work=hotfix, before you switch away.

4

Switch back

On Restore, change Value to feature-wip. Restore that card onto the same database. You are back at the parked schema. Continue the feature.

If Restore does not show the state you want

Filter Value must match the tag on that snapshot. Empty Value lists every value of that tag as separate cards.
Need an older version that shares tags with a newer one → Restore will only show the latest. Open that older version on the Data timeline and Restore from there.
Forgot to park before switching → that in-progress database is overwritten. You cannot get it back unless a snapshot already existed.

Not this page

Custom steps after restore (Clear Redis, scripts) — put them on a restore flow under Flows.
Promote lookups without wiping the rest of the database — Migrate Config and Reference Data.
Repeating the same restore for a test suite — tester restore guide.