Author Archives: Stanislav_Panteleev

Liquibase integration in Spring Boot is pretty straightforward: Boot auto-configures it and runs migrations on startup (before your app starts serving traffic), as long as Liquibase is on the classpath and you point it to a changelog. 1) Add the … Continue reading →

These are Liquibase-specific escape hatches, and interviewers expect you to know why they exist and why they’re dangerous. runAlways runAlways=true means the changeset executes every time Liquibase runs, even if it was already applied. Example Key properties Ignores execution history … Continue reading →

You enforce it with process + CI + runtime gating so there’s no “optional” path. 1) CI: fail if schema isn’t produced only by migrations Golden rule: tests must start from an empty DB and run migrations. In CI, spin … Continue reading →

Short rule (memorize this) PostgreSQL supports transactional DDL; MySQL and Oracle mostly do not. Now the precise breakdown 👇 PostgreSQL ✅ Best-in-class transactional DDL Supports rollback for most DDL: Transactional CREATE TABLE ALTER TABLE DROP TABLE ADD/DROP COLUMN CREATE INDEX … Continue reading →

This is a classic senior trap question. The key is: the database decides, migration tools just adapt. Core rule (memorize this) Migration tools run each migration inside a transaction only if the database supports transactions for the statements being executed. … Continue reading →

Automatic migration testing = spin up a real DB in CI, apply migrations, and assert schema + data + invariants. Anything less is false confidence. What to test (in order of value) 1) “Migrations apply cleanly from empty DB” Create … Continue reading →

What “migration conflict” usually means Two branches add migrations that collide: same version (Flyway V12__…) same object change (both alter users table) One branch merges and the other now fails in CI/prod People “fix” by editing old migrations (🚫) Flyway … Continue reading →

Short answer: the migration tool will fail fast and refuse to continue — and that’s a feature, not a bug. All serious migration tools do checksum validation. After a migration is applied The tool stores metadata in a DB table: … Continue reading →

Forward-only migrations Forward-only migrations can only move the schema forward; mistakes are fixed by adding new migrations, not by reverting old ones. How it works Apply V5 Something’s wrong → create V6 to fix or compensate History is immutable Why … Continue reading →

Strategy A: Use a DB-agnostic migration layer (best for “works everywhere”) Liquibase (recommended) Write declarative changes (types, constraints, indexes) and let Liquibase generate vendor SQL. Key techniques: Use Liquibase change types (createTable, addColumn, addForeignKeyConstraint) instead of raw SQL. Use properties … Continue reading →