Database migrations

Schema changes go through Prisma migrations so each step is reproducible and reversible. Editing schema.prisma without generating a migration risks data loss, because Prisma has no recorded path from the old shape to the new one.

Applying migrations

Development, generates missing migrations and can reset data:

bun run --cwd packages/prisma db-migrate

Production, applies existing migrations only:

bun run --cwd packages/prisma db-deploy

Creating a migration

After changing packages/prisma/schema.prisma:

bun run --cwd packages/prisma db-migrate

Prisma asks for a short name describing the change (for example user_add_email_verified). Commit the generated migration alongside the code that depends on it.

Seeding feature flags

Feature flags are seeded through migrations. Create an empty one:

bun run prisma migrate dev --create-only --name seed_<feature_name>_feature

Then fill in the SQL:

INSERT INTO "Feature" ("slug", "enabled", "type", "description", "createdAt", "updatedAt")
VALUES
  ('your-feature-slug', false, 'OPERATIONAL', 'Description of feature', CURRENT_TIMESTAMP, CURRENT_TIMESTAMP)
ON CONFLICT ("slug") DO NOTHING;

Error: the database schema is not empty (P3005)

Prisma records applied migrations in a _prisma_migrations table. When that record disagrees with the actual database it refuses to continue:

Error: P3005
The database schema for `localhost:5432` is not empty.

Mark each already-applied migration as resolved:

bun run prisma migrate resolve --applied <migration_name>

Resetting a local migration state

When a local database has drifted beyond repair, clear the migration log:

DELETE FROM "_prisma_migrations";

Then re-register every migration in the directory:

ls -1 packages/prisma/migrations/ | grep '^20' | xargs -I{} bun run prisma migrate resolve --applied {}

Missing enum or type errors

If TypeScript complains about enum members that clearly exist in the schema, the generated client is stale:

bun run prisma generate