Introduction
Migrations keep track of changes to your database structure. This helps you update your database safely and in order.
Migrations keep track of changes to your database structure. This helps you update your database safely and in order.
CREATE TABLE table_name ( column_name data_type constraints ); -- Migration files are usually named with a version number or timestamp, like: -- 001_create_users_table.sql -- 002_add_email_to_users.sql
users with two columns.-- 001_create_users_table.sql
CREATE TABLE users (
id SERIAL PRIMARY KEY,
name TEXT NOT NULL
);email to the existing users table.-- 002_add_email_to_users.sql
ALTER TABLE users ADD COLUMN email TEXT;First migration creates a products table. Second migration adds a price column.
-- 001_create_products_table.sql CREATE TABLE products ( id SERIAL PRIMARY KEY, name TEXT NOT NULL ); -- 002_add_price_to_products.sql ALTER TABLE products ADD COLUMN price NUMERIC;
Always test migrations on a copy of your database before applying to production.
Versioning prevents conflicts when multiple people change the database.
Migrations track changes to your database step-by-step.
Version numbers or timestamps keep migrations in order.
This helps teams update databases safely and consistently.
001_init.sql, 002_add_email.sql, 003_update_password.sql. What happens if you try to apply 003_update_password.sql before 002_add_email.sql?ERROR: relation "users" does not exist. What is the most likely cause related to migration versioning?Pass the test and this pattern moves unknown