> migrations won't be faster when you use a tool like this, they will be slower That statement is conflating some things, re: "tool like this". In most cases,

> migrations won't be faster when you use a tool like this, they will be slower That statement is conflating some things, re: "tool like this". In most cases, schema management tooling is a separate layer above online schema change tooling. Online schema change tools (e.g. pt-online-schema-change) are designed to execute table alterations in a non-disruptive fashion, even if the table is huge and/or being written heavily. These tools are indeed often slower than running an ALTER TABLE directly in the database, because the non-disruptive design involves a more complex set of operations occurring in the background. No real way around that; it's a trade-off. In contrast, schema management tools -- ranging from simple migration tools, to more complex services/daemons -- are focused on tracking schema information (either imperative migrations or declarative desired-state) in a source control repo, and executing SQL either directly or by shelling out to another tool. They sometimes include more complex components such as schema linters, verification logic, schedulers, shard mappings, web GUIs, APIs for checking whether a change has been completed yet, etc. Pgroll is rather unusual in that it overlaps into both domains. That approach has pros and cons, but that isn't my point here; rather, I'd say it's best to avoid generalizing about "tools like this" when discussing a tool that works differently than most other software in the same space. That aside, as someone who has spent most of the majority of the past two decades working on database infrastructure at a wide range of different scales and companies, I largely disagree with your statement about schema changes being a trivial part of the database team's day. In my experience, that only happens in two scenarios, at opposite ends of a spectrum: either a company that isn't making many product changes and therefore doesn't have many corresponding schema changes; OR a company that has enough schema changes for safe self-service schema management automation to be a worthwhile investment. Most "tech" companies do fall into that latter extreme though, and greatly benefit from self-service schema management automation. This is about product development velocity, not table size.