Author Archives: Stanislav_Panteleev

Idempotent means: running the migration twice leaves the DB in the same final state (or the second run is a no-op). In strict tools like Flyway, versioned migrations normally run once, but idempotency still matters for: reruns after partial failures, … Continue reading →

To validate migrations in a PR, you want two different guarantees: Correctness: migrations apply cleanly and produce the expected schema/data. Safety: they won’t brick prod (checksum edits, blocking DDL, non-idempotent backfills, etc.). Here’s what a solid PR pipeline looks like. … Continue reading →

Why Flyway avoids rollbacks DDL is often non-transactional (Postgres CREATE INDEX CONCURRENTLY, MySQL online DDL, etc.). Data migrations are irreversible (backfills, deletes, transforms). Automatic rollback scripts give a false sense of safety. Flyway chooses forward-only, auditable history over fragile reversibility. … Continue reading →

You version-control large changelog histories by treating them as immutable audit logs, then adding structure + baselines so new environments don’t have to replay 5 years of history every time. 1) Immutable history + “append-only” rules Never edit applied migrations; … Continue reading →

In GitOps, the key shift is: Git is the desired state, and your CD controller (Argo CD / Flux) is the executor. So migrations must be declarative, repeatable, observable, and safe under retries. Core principles Immutable migrations: never edit an … Continue reading →

Duplicate changesets are mostly a process + CI guardrail problem. You detect them by validating metadata uniqueness and prevent them by naming conventions + automation. What “duplicate” means Liquibase A changeset is uniquely identified by the triple: (id, author, filePath) … Continue reading →

2) Check migration metadata tables (source of truth) This tells you whether it ran, failed, or got stuck. Flyway Query flyway_schema_history: success = false rows → failed migration installed_rank / version to see order checksum and execution_time for clues Liquibase … Continue reading →

Checksum mismatches happen when the migration tool detects that a migration it already recorded as “applied” is not byte-for-byte the same anymore. That’s a feature: it protects you from silently changing production history. What causes a checksum mismatch Flyway Flyway … Continue reading →

Here are folder hierarchies I’d recommend (and why). I’ll give you two “battle-tested” layouts: one for Flyway (SQL-first) and one for Liquibase (master + includes). Both are designed to minimize merge conflicts, support multi-env, and keep things discoverable. Flyway folder … Continue reading →

In read-replica or sharded setups, the “migration problem” isn’t writing SQL — it’s orchestration + safety: where you run it, in what order, how you handle heterogeneity, and how you keep the app compatible during the rollout. Read replicas Core … Continue reading →