Hacker News Reader

Comment by nikita | Hacker News Reader

This is a tricky problem to solve. Reverting to the commit - that's easy and we have all the infrastructure already to allow you to do that. The tricky part is

* Make a schema change

* push into prod

* accumulate some new data

* revert just the schema change

In our discussions we call this separating schema and data and allow you to have different schemas on the same data.

It's tricky to do in Neon due to the fact that storage knows nothing about schemas. It stores page with no idea what's on them.

But we have some ideas how to do this with logical replication where we will run a transform on top of logical replication stream to keep two branches in sync. Not this year though.

View on HN

This would be the killer 2050 alien feature. Git is a really good mental model on itself. Git + Neon = you invent the future!

It would be a killer feature, but the thing is that Git has a conflict resolution feature that puts the working tree in an invalid state until the user has manually fixed certain issues, so that you cannot commit until you manually fix the files and mark those as such.

Doing so for a database seems less desirable from an availability perspective, especially with high-throughput databases.

I've been wondering if it makes sense for databases to start offering CRDTs natively, so that you can perform merges that are algorithmically conflict-free.

CRDTs are pretty hard to implement at the Neon storage level - pages don’t know what’s written on them. I don’t know of a general purpose database that supports CRDTs. It would be cool though!

In a sense, a CRTD is a database. But the 'conflict-free' is only because it defines semantics for conflicting operations.

But, because SQL has conflict resolution by cancellation of one of the two conflicting modifications, I don't think that it is reasonable (or even possible) to merge 2 divergent databases in a single way that always conforms to the needs of the developer and/or application.

But the manual intervention of conflict resolution in a Git repo is done in a working tree. The named branch's HEAD remains the same until the conflict has been resolved and the commit is merged/pushed. So nobody sees the conflict at all, they only ever see either the old code, or the merged resolved code.

Reply on news.ycombinator.com