[itslennysfault]

How is this better than existing migration solutions? More specifically, what does this give me that I'm not getting using the migration provided by an ORM?

Current migration implementations live on the software side and are essentially a folder full of sequential, date stamped, SQL commands to execute. These files are checked into git so they are versioned.

No offense to you or your team or this project, but I obviously trust the Postgres core team far more than you. However, everything is about trade-offs. So, what (briefly) makes this a risk worth taking?

[hahn-kev]

From what I understand it's less about Schema history or migrations, then it is about data history. So if your data was stored in a VCS but it was also a Db. So you could query the database as it was last Thursday, just like you might look at an old version of a file in Git

[itslennysfault]

Interesting. I don't think I've ever really needed that capability, but it is a pretty cool concept.

I HAVE needed an old version of a database to check/compare something, but nightly backups have always sufficed, and for disaster recovery I typically have point-in-time recovery set up. So if a migration goes boom I can just say, "ummmm lets go back to a couple minutes ago" which is a nice safety net.

[Hydrocharged]

hahn-kev made a really good comparison, but it can go a step further. Not only can you query the data at some previous point in time, but you can even run a join across old and current data. If you look at it from the perspective of commits and working sets, then the working set is just the "current" commit, and commands implicitly target the current commit. We give you explicit control over which commit is being referenced, so there's a lot of power in the model.

Recovery is a valid use-case for version control, but fully applying it to data opens up possibilities that haven't really been explored before.