What if your database could update itself safely every time you change your code?
Why Prisma migrations in NestJS? - Purpose & Use Cases
Imagine you have a growing database for your NestJS app. Every time you change a table or add a new field, you have to write SQL scripts by hand and run them carefully on each environment.
Manually writing and running SQL migrations is slow and risky. You might forget a step, cause data loss, or have different database versions on your team. It's hard to keep track of changes and fix mistakes.
Prisma migrations automate this process. They track your database schema changes in code, generate safe migration files, and apply them consistently across all environments.
ALTER TABLE users ADD COLUMN age INT;
npx prisma migrate dev --name add-age-to-users
You can evolve your database schema confidently and quickly, without worrying about errors or inconsistencies.
When adding a new feature that needs a "birthdate" field in the users table, Prisma migrations create and apply the change smoothly on your local machine, staging, and production servers.
Manual database changes are error-prone and hard to track.
Prisma migrations automate schema updates safely and consistently.
This saves time and reduces risks when evolving your app's data.
Practice
Solution
Step 1: Understand Prisma migrations role
Prisma migrations help update the database schema to match changes in your code models.Step 2: Compare options
Options A, B, and C relate to performance, UI, and authentication, which are unrelated to migrations.Final Answer:
To keep the database schema in sync with the application code -> Option DQuick Check:
Prisma migrations = sync DB schema [OK]
- Confusing migrations with frontend code generation
- Thinking migrations handle user sessions
- Assuming migrations optimize API speed
Solution
Step 1: Identify the correct command for creating migrations
The commandnpx prisma migrate dev --nameis used to create and apply migrations during development.Step 2: Eliminate incorrect commands
migrate deployapplies migrations in production,generatecreates Prisma client code, andmigrate resetresets the database.Final Answer:
npx prisma migrate dev --name addUserTable -> Option AQuick Check:
Dev migrations use migrate dev [OK]
- Using migrate deploy instead of migrate dev for new migrations
- Confusing generate with migration commands
- Trying to reset DB when creating migrations
model User {
id Int @id @default(autoincrement())
email String @unique
name String?
}
// Command run:
npx prisma migrate dev --name addNameFieldSolution
Step 1: Analyze schema change
The schema adds an optional 'name' field to the User model, which is a valid change.Step 2: Understand migrate dev behavior
Runningnpx prisma migrate dev --name addNameFieldcreates a migration file reflecting this change and applies it to the database.Final Answer:
A migration file is created adding the optional 'name' field to User table -> Option CQuick Check:
Optional field added = migration created [OK]
- Thinking optional fields cause errors
- Assuming schema stays unchanged without manual DB update
- Believing migrate dev deletes tables
npx prisma migrate deploy in production but get an error saying migrations are missing. What is the likely cause?Solution
Step 1: Understand migrate deploy requirements
migrate deployapplies existing migration files to production; it does not create them.Step 2: Identify cause of missing migrations error
If migration files were not created locally (e.g., with migrate dev), deploy will fail due to missing files.Final Answer:
You forgot to create migration files locally before deploying -> Option AQuick Check:
Deploy needs existing migrations [OK]
- Confusing migrate dev and migrate deploy roles
- Ignoring missing migration files
- Assuming wrong DB connection causes missing migrations error
age Int to your User model in Prisma. However, your database already has existing users without this field. What is the best way to handle this migration safely?Solution
Step 1: Understand required field impact
Adding a required field means existing rows must have a value, or migration will fail.Step 2: Apply a two-step migration strategy
First add the field as optional, migrate, update existing data with values, then change field to required and migrate again.Final Answer:
Add the field as optional first, run a migration, then update data and make it required in a second migration -> Option BQuick Check:
Two-step migration avoids missing data errors [OK]
- Adding required fields directly causing migration failure
- Deleting data unnecessarily
- Skipping migrations and editing DB manually
Ready to prove it?
Pass the test and this pattern moves unknown
