prisma-migrations

# Prisma Migrations

Manage database schema changes with Prisma Migrate for version-controlled, reproducible migrations.

## Migration Commands

| Command | Environment | Purpose |
|---------|-------------|---------|
| `prisma migrate dev` | Development | Create and apply migrations |
| `prisma migrate deploy` | Production | Apply pending migrations |
| `prisma migrate reset` | Development | Reset database and apply all migrations |
| `prisma migrate status` | Any | Show migration status |
| `prisma db push` | Development | Push schema without migration history |

## Development Workflow

### Create a Migration

```bash
# Interactive: prompts for migration name
npx prisma migrate dev

# Non-interactive: provide name
npx prisma migrate dev --name add_user_email

# Create without applying (for review)
npx prisma migrate dev --create-only --name add_user_email
```

### Migration File Structure

```
prisma/migrations/
├── 20240101120000_init/
│   └── migration.sql
├── 20240115143000_add_user_email/
│   └── migration.sql
└── migration_lock.toml
```

**Important:** Never manually create or edit files in `prisma/migrations/`. Always use `prisma migrate dev`.

### Check Migration Status

```bash
npx prisma migrate status
```

Output shows:
- Applied migrations
- Pending migrations
- Failed migrations
- Database drift

## Production Workflow

### Deploy Migrations

```bash
# Apply all pending migrations
npx prisma migrate deploy
```

Use in CI/CD pipeline or deployment scripts:

```bash
# Example deployment script
npx prisma migrate deploy
npx prisma generate
npm run start
```

### Migration Status in Production

```bash
# Check without applying
npx prisma migrate status
```

## Common Scenarios

### Adding a Required Field

When adding a required field to existing data:

```prisma
model User {
  id    Int    @id
  email String  // New required field
}
```

Options:
1. **Provide default in migration** - Edit generated SQL
2. **Make nullable first** - Add as optional, backfil