Snapshots

A snapshot records your project's schema as it was at a moment: tables, columns, types, foreign keys. It is a structural capture, not a copy of your rows.

Open a project and go to Snapshots.

Why bother

Schemas move. Somebody adds a column, renames a table, drops a constraint. When generation starts behaving differently, the useful question is "what changed?", and a snapshot is what lets you answer it rather than guess.

The common uses:

• Capture before a migration, so you can compare after
• Keep a known-good structure to restore to when an experiment goes sideways
• Give a scheduled backup something to write to on a cadence

Capturing

Click Capture. That is the whole flow. The snapshot is timestamped and listed newest first.

Pinning

Pinned snapshots stay put and are exempt from cleanup. Pin the ones that mean something, such as the state before a big migration, so they do not get lost among routine captures.

Restoring

Restore returns the project to that snapshot's schema.

Restoring affects the project's understanding of your structure. It does not reach into your database and undo migrations, and it does not delete rows. If your real schema has moved on, restoring an old snapshot will make SeedQL generate against a structure that no longer matches, and the push will fail on the mismatch. Restore is for recovering SeedQL's view, not for rolling back your database.

Deleting

Snapshots can be deleted, with a confirmation. Deletion is permanent.

Scheduled snapshots

On Business and Enterprise, snapshots can be captured automatically on a cadence. See Schedules.