absolute db

Run absolute db <backup|restore|seed> from your project root. The connection comes from DATABASE_URL (or POSTGRES_URL), or pass --url. Nothing is ORM-specific — it talks to Postgres directly, so it behaves the same whether you use Drizzle, Prisma, Kysely, or raw SQL.

# Back up every table to backups/<timestamp>.json (+ latest.json)
absolute db backup

# Scope, exclude, or send the dump elsewhere
absolute db backup --only users,posts
absolute db backup --exclude sessions --out ./snapshots

# Idempotent restore — upsert each row by primary key, foreign-key ordered
absolute db restore                      # newest backup: backups/latest.json
absolute db restore ./snapshots/backup-2026-05-25.json

# Wipe matching tables first, then restore (confirms; -y skips the prompt)
absolute db restore --truncate -y

# Run the project's seed script (db/seed.ts by default)
absolute db seed
absolute db seed ./db/demo-seed.ts

backup dumps every table to a timestamped JSON file plus latest.json; scope it with --only, --exclude, and --out. restore is idempotent — it upserts each row by its real primary key, ordered so parent tables land before the rows that reference them, so re-running it changes nothing. Add --truncate for a clean reload (it confirms first, or pass -y). seed runs your project’s seed script (db/seed.ts by default, or a path you pass).

$ absolute db backup
  ✓ backup → backups/backup-2026-05-25T18-30-42-239Z.json
    8 tables, 1240 rows

$ absolute db restore
  ✓ restored 8 tables, 1240 rows (idempotent upsert by primary key)

The command introspects your database’s own catalog (information_schema) to discover tables, primary keys, and foreign keys, then reads and writes rows with Bun’s built-in SQL client — no extra dependencies and no coupling to your ORM. Because restore keys off the real primary key, it is safe to run repeatedly and safe to bake a backup into your recovery runbook.