Comment by evanelias

Disclosure: I'm the creator of Skeema (https://www.skeema.io), a declarative schema management system for MySQL/MariaDB mentioned at the bottom of the original article.

> migrations are a sequence of transformations stored in files on disk [...] This keeps everything in version control

While traditional migration systems do give you something to put in version control, I'd argue that what they give you is the wrong abstraction, at least for schema management / DDL.

The migration files need to be ordered in some way based on their filenames, and their contents contain imperative DDL that must be executed in that order. This is conceptually equivalent to storing a bunch of .patch files in a git repo, and then using a file naming scheme to indicate the intended application of patches.

But, version control systems already have a first-class notion of ordering and diff'ing -- after all that's one of the main purposes of the version control system! So at best this scheme is redundant, and at worst it's a second source-of-truth which may conflict.

And then, separate from the repo ordering/source-of-truth problem, you also have a third source of truth which may conflict: the actual state on any given database server, which could also include further drift. Sometimes things get run out-of-order in the course of development, sometimes people run things manually as part of an emergency hot-fix, etc.

Finally, there's the additional problem of these migration files not truly being immutable. If someone accidentally edits, deletes, or renames one of these migration files, the result is basically undefined, if that migration has already been executed on at least one database environment. Some migration systems store hashes of the migration contents, which helps for catching the edited migration after execution case, but not the other cases.

> and means there's no chance of the wrong migration being applied in the wrong way.

Assuming that your commit order, filename order, and execution order are always all aligned, and your migration files are immutable, this is true. And some engineers really value having that history of ALTER TABLE statements.

But of course there's another wrinkle, at least in MySQL/MariaDB as well as SQLite: there are many situations where you're not really using ALTER TABLE, but instead are using a separate external tool to mimic the desired effects of the ALTER, due to various peculiarities and shortcomings of the database's ALTER support.

So if you're not really running an ALTER anyway, is a repo with a bunch of name-ordered ALTER statements even valuable? In contrast, a declarative system gives you a repo which expresses the intended state of the database, which may be used as an easy reference for engineers, and also contains useful `git blame` results to see why/when/who made a change.

That all said, I do concede that imperative migrations are useful for data migrations (DML), as well as renames (renaming a table or renaming a column within a table). The declarative model doesn't capture imperative changes. But nothing prevents you from using a declarative system for schema changes and pairing it with a traditional migration system for imperative changes.