Database migrations with the Sequelize CLI
versioned, repeatable schema changes.
migrations are version-controlled scripts with up/down so teams apply identical schema changes; use sequelize-cli to generate, edit with addColumn, then db:migrate.
What's really being asked
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.
The full answer
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.
The mistakes people make
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.
What usually comes next
How do you roll back? How do migrations differ from seeders? Why avoid sync in production? How does Sequelize track which migrations ran (SequelizeMeta)?
A 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.
Interview question
Why are committed Sequelize migrations preferred over each developer manually altering their local database?
- a.They eliminate the need for a database connection
- b.They make queries run faster at runtime
- c.They give every environment the same ordered, reproducible, reversible schema changesCorrect
- d.They automatically generate seed data for tests
Why? this is the answer
Migrations are version-controlled scripts with up/down applied in order, so all environments converge on an identical schema with rollback support. They concern structure, not query speed, and are distinct from seeders.
Just read this? Test yourself on what you have been reading.
Read the original → sequelize.org
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on nodejs — each one lists the topics its interview covers.
See open roles