5 ms·

This is definitely a challenge and something you have to address when building on top of Postgres because of its architecture. But I want to highly encourage pe

This is definitely a challenge and something you have to address when building on top of Postgres because of its architecture. But I want to highly encourage people that you can avoid having to deal with this stuff if you approach it with CRDTs (go google them, they are fun!), like what with Cassandra does - (edit: disclaimer, I work for a competing system) I did this tech talk ( http://gun.js.org/distributed/matters.html http://gun.js.org/distributed/matters.html ) a few years ago in Berlin on the things to avoid and the possible solutions (and their tradeoffs / dangers).

kaghyu1667 9y ago
Please stop spamming this.
Twisol 9y ago
I'm actually very interested in CRDTs and related approaches, and I've been exploring active research directions in the area, but I'm not sure they share many usage patterns with data stores like Postgres, which support very general access and update semantics. The primary restriction for anything involving CRDTs is that no operation can "take back" something added by a previous operation, so the data in question can only evolve monotonically. It's great when you can get away with it, but it's unclear how often you can actually get away with it.
- marknadal 9y ago
  Yes, very true. Kyle Kingsbury was at the conference and I talked to him about this, and his conclusion from his research is that Postgres is still all around the best database out there. Especially if you need to do things that CRDTs aren't yet equipped to handle. Have you made a compilation of your thoughts from the various research you've done? Would love to see them!
mayank 9y ago
It's generally good form here to put in a disclaimer when you're plugging your own product.
greenleafjacob 9y ago
Warning: Cassandra counters are not backed by CRDTs [1]. [1] https://aphyr.com/posts/294-jepsen-cassandra https://aphyr.com/posts/294-jepsen-cassandra
- iamaleksey 9y ago
  Except they are. Catalogued as δ-CRDT, under Lexicographic Counter in https://arxiv.org/pdf/1603.01529.pdf https://arxiv.org/pdf/1603.01529.pdf edit: Although to be fair that blog post is ancient and covers Cassandra 2.0, now no longer supported. Counters were rewritten in Cassandra 2.1.

kaghyu1667 9y ago

Please stop spamming this.

Twisol 9y ago

I'm actually very interested in CRDTs and related approaches, and I've been exploring active research directions in the area, but I'm not sure they share many usage patterns with data stores like Postgres, which support very general access and update semantics. The primary restriction for anything involving CRDTs is that no operation can "take back" something added by a previous operation, so the data in question can only evolve monotonically. It's great when you can get away with it, but it's unclear how often you can actually get away with it.

marknadal 9y ago
Yes, very true. Kyle Kingsbury was at the conference and I talked to him about this, and his conclusion from his research is that Postgres is still all around the best database out there. Especially if you need to do things that CRDTs aren't yet equipped to handle. Have you made a compilation of your thoughts from the various research you've done? Would love to see them!

mayank 9y ago

It's generally good form here to put in a disclaimer when you're plugging your own product.

greenleafjacob 9y ago

Warning: Cassandra counters are not backed by CRDTs [1]. [1] https://aphyr.com/posts/294-jepsen-cassandra https://aphyr.com/posts/294-jepsen-cassandra

iamaleksey 9y ago
Except they are. Catalogued as δ-CRDT, under Lexicographic Counter in https://arxiv.org/pdf/1603.01529.pdf https://arxiv.org/pdf/1603.01529.pdf edit: Although to be fair that blog post is ancient and covers Cassandra 2.0, now no longer supported. Counters were rewritten in Cassandra 2.1.