3 ms·
The other dark side of implementations using CRDTs is the infrastructure load. I wrote about this [0] in depth previously, and Supabase wrote an article [1] a c
by sgarland 2y ago
The other dark side of implementations using CRDTs is the infrastructure load. I wrote about this [0] in depth previously, and Supabase wrote an article [1] a couple of years ago about a CRDT extension for Postgres which I'm happy to discover agrees with my empirical findings.
If you're going to use CRDTs, do yourself a favor and either use Redis or similar (though the amount of memory being consumed is painful to think about), or MyRocks [2] (or anything else based on RocksDB / LevelDB). Whatever you do, do _not_ back it with an RDBMS, and especially not Postgres.
[0]: https://news.ycombinator.com/item?id=40834759 https://news.ycombinator.com/item?id=40834759
[1]: https://supabase.com/blog/postgres-crdt https://supabase.com/blog/postgres-crdt
[2]: http://myrocks.io http://myrocks.io
- michaelsalim 2y agoThanks for this. Seems really useful since I'm building using Yjs + Postgres myself. Might save the day one of these days!
- satvikpendem 2y agoPowerSync has an article on using Postgres with Yjs (and perhaps look into Yrs, the Rust implementation, as well as other Rust crates like Loro and Automerge that are much faster) and they use a table in the database that stores the changes, is that what you are doing too [0]? [0] https://www.powersync.com/blog/postgres-and-yjs-crdt-collaborative-text-editing-using-powersync https://www.powersync.com/blog/postgres-and-yjs-crdt-collabo...