{
  "id": 9039962,
  "title": "6 Lessons From 20 Years of SQL Migration Tools (Applied to a NoSQL Migrator in 2026)",
  "url": "https://urgent.news/2026/09/21/6-lessons-from-20-years-of-sql-migration-tools-applied-to-a-nosql",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-09-21T23:51:41.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/keymelgaston/6-lessons-from-20-years-of-sql-migration-tools-applied-to-a-nosql-migrator-in-2026-1ah"
  },
  "original_language": "en",
  "account": "In 20 years of SQL migration tools like Flyway (2010), Liquibase (2006), and dbmate, engineers have developed hard-earned lessons on safely, repeatedly changing database schemas without losing data. These lessons, however, have not been applied to NoSQL-to-SQL migrations, despite the open-source nature and battle-tested production use at major companies. The author decided to explore these lessons by examining existing SQL migration tools.\n\n1. Convention over configuration: Flyway uses the filename to determine execution order, such as V2__add_orders_table.sql, eliminating the need for configuration files or databases specifying what runs when. The recommended approach is to create versioned, predictably-named files in the filesystem, reviewable in Git, rather than relying on hidden states inside the tool's memory.\n\n2. Dirty state as a safety feature: If a Flyway migration fails, it marks the schema as dirty and prevents further execution until a human verifies its safety to continue. This is different from most tools, which continue trying when something goes wrong. Flyway's approach is to stop and require a human decision, providing a better default when production data might be silently corrupted.\n\n3. Dumping the schema after each step: dbmate writes a plain, readable db/schema.sql file after each migration, allowing for easy diffing in Git. This provides concrete evidence of the current state rather than relying on a log that scrolls off the terminal.\n\n4. Staying a small, boring binary: dbmate is a minimal binary with one environment variable for the connection string, lacking an ORM, plugin system, or framework opinions. This simplicity makes it easier to maintain for free, preventing it from becoming a platform instead of a migration tool.\n\n5. Rollback is the user's job: Liquibase Community requires users to write their own rollback scripts, rather than providing a generic undo button. This approach is honest, as reversing a migration cleanly can be a different and more challenging problem than applying it in the first place.\n\n6. Separate the \"what changes\" from the \"how it runs\": Liquibase keeps the changelog (SQL, YAML, JSON, XML) as a distinct artifact from the execution engine, allowing for separate review and versioning of the changelog without running anything. This separation is particularly important for NoSQL-to-SQL migrations, where inferred structure is crucial. Borrowing this separation can help ensure that the proposed schema is something humans can read and edit calmly, in a file, before any changes are made to the database.",
  "summary": "Flyway has been around since 2010. Liquibase since 2006. dbmate is newer but built on the same lineage. Between them, that's decades of hard-won engineering on one narrow problem: how do you change a database schema safely, repeatedly, without losing anyone's data. Here's the part that surprised me: none of that engineering ever made it over to NoSQL-to-SQL migrations. Not because it's secret…",
  "key_points": [],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}