Database migrations with the Sequelize CLI

WHAT THIS TESTS This assesses whether you treat schema changes as versioned, reproducible artifacts rather than ad-hoc manual edits, which is essential for team and multi-environment work.

A GOOD ANSWER COVERS A migration is a version-controlled script that describes a schema change, with an up method that applies it and a down method that reverts it. Migrations are ordered (usually timestamped) and committed to source control, so every teammate and every environment, development, staging, and production, applies the exact same sequence of changes and arrives at an identical schema. This eliminates 'works on my machine' drift, makes changes reviewable, and provides a rollback path. With Sequelize you generate a migration via the CLI, npx sequelize-cli migration:generate --name add-status-to-tasks, which scaffolds a file. You edit the up method to call queryInterface.addColumn('Tasks', 'status', { type: Sequelize.STRING, defaultValue: 'open' }) and the down method to call queryInterface.removeColumn('Tasks', 'status'). You then apply pending migrations with npx sequelize-cli db:migrate, and can revert with db:migrate:undo.

COMMON WRONG ANSWERS Editing the database schema manually in each environment, causing drift. Writing only the up method and leaving down empty, losing rollback safety. Not committing migrations so teammates miss them. Confusing migrations with seeders (data) rather than structure. Relying on Sequelize sync({ alter: true }) in production, which is risky.

LIKELY FOLLOW-UPS How do you roll back? How do migrations differ from seeders? Why avoid sync in production? How does Sequelize track which migrations ran (SequelizeMeta)?

ONE CONCRETE EXAMPLE In the generated file: async up(queryInterface, Sequelize) { await queryInterface.addColumn('Tasks', 'status', { type: Sequelize.STRING, defaultValue: 'open' }); } async down(queryInterface) { await queryInterface.removeColumn('Tasks', 'status'); } Running db:migrate adds the column everywhere consistently, and db:migrate:undo removes it, so the schema change is reproducible and reversible across the whole team.