Migrations

Prisma owns the migration workflow. Local development uses migrate dev. Production deploys use migrate deploy (wired into deploy as a release / pre-deploy step).

Day-to-day commands

From the project root:

# Create a migration from schema changes and apply it locally
pnpm --filter @hype-stack/backend prisma:migrate

# Apply committed migrations without prompting (CI / production)
pnpm --filter @hype-stack/backend exec prisma migrate deploy

# Open Prisma Studio against your local database
pnpm --filter @hype-stack/backend exec prisma studio

Exact script names live in apps/backend/package.json. If your project exposes migration:latest, deploy prefers that; otherwise it falls back to prisma migrate deploy.

After installing a pack

compose and template merge pack Prisma files into your schema. That does not apply SQL by itself.

1. Inspect the merged schema under apps/backend/prisma/
2. Run prisma:migrate (or your project's migrate script)
3. Confirm the generated client and Kysely types still typecheck

Skipping this step is the most common "tables do not exist" failure after adding auth, billing, or teams.

Seed data

When the project defines a seed script:

pnpm --filter @hype-stack/backend exec prisma db seed

Seeds are for local and demo data. Do not treat seed SQL as the production source of truth for roles or tenants.

Staging and production discipline

Before a production deploy:

1. Generate migrations intentionally on a feature branch
2. Review the generated SQL
3. Apply with migrate deploy (or let hype-stack deploy run it)
4. Verify the app against the migrated schema

Never point a local migrate dev at a shared staging database. That command can reset and rewrite history.

Related

• Prisma and Kysely for when to use each tool
• Deploy for how Fly and Railway run migrations
• Going to production for the full checklist
• Troubleshooting if migrate cannot connect