Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The first CRDTs have been remarkably impractical, e.g. WOOT[0]. These days, state-of-the-art CRDT databases are not much different from your regular LSM performance-wise. For example, RDX CRDTs[1,2] are all implemented by a merge-sort-like algorithm, pure O(N). Metadata overheads have been tamed in most implementations.

[0]: https://github.com/el10savio/woot-crdt

[1]: https://github.com/gritzko/librdx

[2]: https://github.com/gritzko/go-rdx



Do you have benchmarks at scale, ideally compared to other store / DB implementations? I’ve seen other CRDT libraries using Postgres (inadvisedly) bring it to its knees due to the massive amount of chattiness and updates.


RDX works as a merge operator inside virtually any LSM database. It is strictly O(N), so almost every LSM db benchmark would be relevant here.

There is an RDX-specific LSM engine BRIX, but that one is good for its Merkle properties.

Chotki is basically Pebble.


>For example, RDX CRDTs

No affiliation, right?


I am the author of RDX. I let others brag about thier implementations.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: