Database Migrations
Review and apply D1 migrations with backups and release checks.
D1 / SQLite uses its own reviewed migration history.
| Schema | Configuration | Migrations |
|---|---|---|
packages/db/src/schema-d1.ts | packages/db/drizzle.config.d1.ts | packages/db/migrations-d1/ |
D1
pnpm db:generate:d1
pnpm db:migrate:d1:local
pnpm db:seed:d1
pnpm db:migrate:d1:status
pnpm db:migrate:d1:remote
pnpm db:migrate:d1:status --strictThe generator maintains SQL hashes in packages/db/migrations-d1/manifest.json and refuses changes to recorded migrations. Remote migration exports a backup, tests migration and foreign keys on a local clone, then applies remotely. Align the demo database name in scripts/d1-migrations.ts with your wrangler.jsonc; scripts/seed-d1.ts uses the DB binding rather than a hardcoded database name. See Cloudflare deployment.
pnpm cf:deploy checks remote history against local files before release and stops on pending migrations. Do not treat pnpm cf:upload as a substitute for that gate.
Existing Databases
The latest version resets the baseline. Do not apply the new 0000_initial.sql as an upgrade migration to an existing production database. Legacy databases may have old journals and settings tables: back up, compare schema/history on a clone, and design incremental migrations for your derivative. Current root scripts have neither a legacy settings export command nor drizzle:* aliases.
Write failing tests first. Append migrations instead of rewriting applied SQL or faking journals. Test the selected schema, SQL queries, defaults, indexes, and failure recovery before release.