𝐇𝐨𝐰 𝐝𝐨 𝐲𝐨𝐮 𝐦𝐢𝐠𝐫𝐚𝐭𝐞 𝐬𝐜𝐡𝐞𝐦𝐚 𝐜𝐡𝐚𝐧𝐠𝐞𝐬 𝐬𝐚𝐟𝐞𝐥𝐲 𝐢𝐧 𝐒𝐩𝐫𝐢𝐧𝐠 𝐁𝐨𝐨𝐭 𝐰𝐢𝐭𝐡 𝐏𝐨𝐬𝐭𝐠𝐫𝐞𝐒𝐐𝐋? 𝐰𝐢𝐭𝐡 𝐑𝐞𝐚𝐥-𝐓𝐢𝐦𝐞 𝐄𝐱𝐚𝐦𝐩𝐥𝐞

=================================

In Spring Boot projects, I handle schema migrations using a versioned migration tool like Flyway or Liquibase, rather than relying on Hibernate auto-DDL. This gives us controlled, repeatable, and auditable database changes across environments

Each schema change is written as a migration script and versioned — for example, adding a column, creating an index, or modifying a constraint. These migrations are applied automatically at application startup or during deployment, and the tool tracks which migrations have already run

To keep migrations safe, I follow a few best practices. First, migrations are backward-compatible whenever possible — for example, adding new nullable columns before removing old ones. Destructive changes like dropping columns are done in later releases after the application code no longer depends on them

Second, all migrations are tested in lower environments using production-like data. We also make sure migrations are idempotent and transactional, which PostgreSQL supports well, so failures can be rolled back safely.

Finally, migrations are part of the CI/CD pipeline, and production changes are always backed up. This way, schema evolution is predictable, reversible when needed, and aligned with application releases

𝐑𝐞𝐚𝐥-𝐓𝐢𝐦𝐞 𝐔𝐬𝐞 𝐂𝐚𝐬𝐞: 𝐒𝐚𝐟𝐞𝐥𝐲 𝐀𝐝𝐝𝐢𝐧𝐠 𝐚 𝐍𝐨𝐧-𝐍𝐮𝐥𝐥𝐚𝐛𝐥𝐞 𝐂𝐨𝐥𝐮𝐦𝐧

---------------------------------------

𝐒𝐜𝐞𝐧𝐚𝐫𝐢𝐨 :

We had a users table in PostgreSQL, and the business requirement was to add a status field to track whether a user is ACTIVE, SUSPENDED, or DELETED. The application is already live with millions of records

𝐏𝐫𝐨𝐛𝐥𝐞𝐦

We can’t directly add a NOT NULL column, because existing rows don’t have values and it would either fail or cause downtime

𝐒𝐭𝐞𝐩 1: 𝐀𝐝𝐝 𝐭𝐡𝐞 𝐜𝐨𝐥𝐮𝐦𝐧 𝐚𝐬 𝐧𝐮𝐥𝐥𝐚𝐛𝐥𝐞

ALTER TABLE users ADD COLUMN status VARCHAR(20);

This change is backward-compatible and doesn’t break the running application

𝐒𝐭𝐞𝐩 2: 𝐁𝐚𝐜𝐤𝐟𝐢𝐥𝐥 𝐞𝐱𝐢𝐬𝐭𝐢𝐧𝐠 𝐝𝐚𝐭𝐚

UPDATE users SET status = 'ACTIVE' WHERE status IS NULL;

This can be done in batches to avoid long-running locks

𝐒𝐭𝐞𝐩 3: 𝐔𝐩𝐝𝐚𝐭𝐞 𝐚𝐩𝐩𝐥𝐢𝐜𝐚𝐭𝐢𝐨𝐧 𝐜𝐨𝐝𝐞

We update the Spring Boot code to always write status for new users

𝐒𝐭𝐞𝐩 4: 𝐀𝐝𝐝 𝐍𝐎𝐓 𝐍𝐔𝐋𝐋 𝐜𝐨𝐧𝐬𝐭𝐫𝐚𝐢𝐧𝐭 𝐢𝐧 𝐚 𝐥𝐚𝐭𝐞𝐫 𝐦𝐢𝐠𝐫𝐚𝐭𝐢𝐨𝐧

ALTER TABLE users ALTER COLUMN status SET NOT NULL;

At this point, the database constraint enforces data integrity safely.”

All these steps are implemented as separate Flyway or Liquibase migrations, versioned and applied through CI/CD. Each release moves the schema forward without breaking running code