zlacker

> Personally I've always called this style "declarative schema management" since the input declares the desired state, and the tool figures out how to transition the database to that state.

Personally I've called it a mistake, since there's no way a tool can infer what happened based on that information.

>>stemch+(OP)
For schema changes, it absolutely can, for every situation except table renames or column renames.

That might sound like a major caveat, but many companies either ban renames or have a special "out-of-band" process for them anyway, once a table is being used in production. This is necessary because renames have substantial deploy-order complexity, i.e. you cannot make the schema change at the same exact instant as the corresponding application change, and the vast majority of ORMs don't provide anything to make this sane.

In any case, many thousands of companies use declarative schema management. Some of the largest companies on earth use it. It is known to work, and when engineered properly, it definitely improves development velocity.

>>evanel+45
Uh, any database of sufficient size is going to do migrations “out of band” as they can take hours or days and you never have code requiring those changes ship at migration start.

Small things where you don’t have DBA or whatever, sure use tooling like you would for auto-changes in a local development.