Skip to main content
Restore downloads a snapshot and inserts its data into a target database. It validates schema compatibility and ensures referential integrity during the process.
Run your migrations first. Restore validates the target schema and inserts data; it does not create or alter tables.

Usage


Arguments

Flags


Examples

Quick Examples


Basic Restore

Apply the latest version of a snapshot to your local database:
What happens:
  1. CLI resolves the latest tag for “weekly-dev-data”.
  2. Downloads manifest and schema metadata.
  3. Connects to the target database and validates schema compatibility.
  4. Downloads data files and inserts rows in dependency order.
  5. Verifies referential integrity across all restored tables.

Clean Restore (Local Development)

Wipe existing data in the target tables before restoring:
When to use --reset:
  • You want to ensure the target tables only contain the snapshot data.
  • You are re-running a seed script and want to avoid duplicate key errors.
  • You want a clean slate for debugging a specific issue.
--reset runs inside the same transaction as restore inserts. If restore fails, all reset and insert operations are rolled back together.

CI/CD Integration

Automate restoration for integration tests:

Analyze Foreign Key Restore Safety

Preview FK-related restore risk before applying any data:
--analyze-fks reports:
  • Number of non-deferrable foreign key constraints.
  • Self-referential tables in the restore scope.
  • Whether an inter-table FK cycle exists.
  • Whether safe restore mode would be blocked.
  • Whether nullable fallback is available for blocking constraints.
If Nullable fallback available: true, Basecut will automatically handle the restore using a two-phase approach — inserting rows with temporary NULLs for the blocking FK columns, then backfilling the real values — with no additional flags required. This requires that all blocking FK columns are nullable and the affected table has a primary key or unique key. Use this when preparing migrations or debugging FK restore blockers.

Unsafe FK Bypass (Last Resort)

If you need a one-off restore and cannot make constraints deferrable immediately:
--unsafe-disable-fk-checks disables FK enforcement during restore. Use only in controlled environments and validate integrity after restore.
This mode may require elevated PostgreSQL privileges.

Output

Success

With Reset


Error Handling

Schema Compatibility Error

Solutions:
  • Run your database migrations to align the target schema with the snapshot.
  • Use --force to skip validation (not recommended if data types have changed).

Foreign Key Constraint Error

Common causes:
  • Non-deferrable foreign keys combined with cyclic or self-referential dependencies.
  • Parent rows missing from target scope while child rows are restored.
Solutions:
  • Run FK preflight first:
  • Make relevant foreign key constraints DEFERRABLE where appropriate.
  • If --analyze-fks reports nullable fallback available, re-run restore normally — Basecut handles it automatically. Note: nullable fallback is not compatible with --on-conflict skip; use the default conflict policy.
  • Ensure referenced parent tables/rows are included in the snapshot.
  • If you need a temporary bypass, use --unsafe-disable-fk-checks (unsafe).
  • Re-run after schema alignment or adjust restore scope.

Conflict Error (--on-conflict error)

Solutions:
  • Use --reset for a clean restore target, or
  • Use --on-conflict skip to continue and skip conflicting rows.

Connection Failed

Solutions:
  • Verify the target database is running.
  • Check the connection string and credentials.
  • Ensure the database is accessible from your network.

Next Steps

Create Snapshot

Learn how to extract data from your source database

Snapshots Concept

Understand the anatomy and lifecycle of snapshots

Snapshot Versioning

Learn how tags and versions work

Troubleshooting

Common issues and how to solve them