> production state + pending changes = goal state That's exactly what Django is doing, btw. > I did a talk at PostgresOpen a while back about the problems wit

> production state + pending changes = goal state That's exactly what Django is doing, btw. > I did a talk at PostgresOpen a while back about the problems with Django-style migrations Good talk generally, and a lot of stuff I agree with. If the migrations sit out for a year in the code base, it's not a big deal though. It looks like a big deal, but in practice, it's not. Migrations can be reset back to zero if you want in Django. But when you're trying to develop in parallel developer environments, the Django migration DAG alerts you when you have two leafs that haven't been merged. And if you ever had to roll back a failed prod deploy, Django supports a backwards migration too. I get what your saying, but in practice the benefit of using Django where the "code is the configuration" is better than trying to keep code and configuration separate and trying to match them up later.