Migrations

Commit the migration

# edit tapedb.schema.ts, then
npx tapedb migrate dev --name add_task_priority

migrate dev diffs the schema against tapedb/schema.snapshot.json and writes the next numbered SQL file, reviewed and committed like any ORM migration, plus the bundle worker.ts imports. Each workspace’s Durable Object applies pending migrations on its next wake, one transaction per migration, with foreign keys switched off around it and checked before it commits. A migration that would leave a row pointing at nothing rolls back.

Rules

• A new required field needs .default(...) or .optional().
• Drops need --accept-data-loss; renames need --rename old=new or --rename model.old=new, otherwise they read as a drop plus an add.
• Type, default and reference changes rebuild the table, including tables other tables reference: child rows keep their keys and nothing cascades.
• Migrations declare what they changed, so recovery can replay log segments and snapshots written under an older schema. Undeclared drift fails closed.

Check and deploy

migrate status lists the committed migrations and reports whether the schema is up to date. migrate check fails CI or a pre-commit hook when the schema has changes with no migration. tapedb deploy refuses to ship a dev configuration or an unmigrated schema, then runs wrangler deploy.

Next: files, presence and broadcast, or understand recovery.