Moose Migrate offers two complementary modes for generating and applying migrations. Each is designed for use in different stages of the application lifecycle, and it's best practice to use both in your workflow:
| Automatic Migrations | Planned Migrations | |
|---|---|---|
| Primary Use Case | Local Development | Production Deployment |
| Trigger | File Save / Watcher | moose generate migration |
| Artifact | None (Immediate SQL Execution) | Migration Plan (plan.yaml) |
| Safety | Low (Optimized for speed) | High (Optimized for safety) |
| Reviewable | No | Yes |
| Drift Detection | No | Yes |
Designed for the "inner loop" of development, Automatic Migrations prioritize velocity. As you iterate on your data models in code, Moose automatically applies the necessary changes to your local database in real-time.
Read the Automatic Migrations Reference →
Designed for the "outer loop" of deployment, prioritize safety. This mode separates the of changes from their , creating a static artifact that can be reviewed, tested, and versioned.
| Scenario | Recommended Mode | Rationale |
|---|---|---|
| Local Prototyping | Automatic | You want to iterate quickly on your schema without running commands for every change. |
| Production Deployment | Planned | You need to ensure that schema changes are safe and do not accidentally delete user data. |
| CI/CD Pipeline | Planned | You need to apply migrations in a deterministic way as part of your deployment process. |
| Renaming Columns | Planned | You need to explicitly tell the database to rename a column instead of dropping and re-adding it. |
| Team Review | Planned | You want to review schema changes in a Pull Request before they are applied. |