[HN Gopher] CRDT and SQLite: Local-First Value Synchronization
___________________________________________________________________
CRDT and SQLite: Local-First Value Synchronization
Author : marcobambini
Score : 51 points
Date : 2025-10-09 14:01 UTC (4 days ago)
(HTM) web link (marcobambini.substack.com)
(TXT) w3m dump (marcobambini.substack.com)
| briandw wrote:
| For a primer on CRDTs, Martin Kleppmann has a number of good
| videos: https://www.youtube.com/watch?v=x7drE24geUw
| withinboredom wrote:
| This works assuming everyone has the same clock or performs
| changes causually distant from each other. It fails to work if,
| say, 1000 people all make a change around the same time. This
| also applies to lamport timestamps.
| marcobambini wrote:
| The algorithm has a way to resolve conflicts even if, by any
| chance, the Lamport clock has the same value in all peers
| withinboredom wrote:
| Yeah, but the fact that they didn't even mention it in their
| post is why I brought it up.
| p1necone wrote:
| If a thousand people all made a change at the same time in a
| totally deterministic, always online system a single one of
| those writes would arbitrarily win in exactly the same way.
|
| In practice "1000 people edit same thing at same time" is not a
| problem that needs to be solved via software, the users are
| just doing silly things and getting silly results.
| withinboredom wrote:
| If it isn't handled correctly, you'll eventually end up with
| parallel histories on different devices. Even if it isn't
| 1000 people, people will share documents with entire
| classrooms, offices, etc., which increases the probability of
| this situation tremendously.
| ncruces wrote:
| CRDTs only care that the end result is _eventually_ the
| same.
|
| It doesn't need to make sense, or be the most recent
| change, only that given the same inputs, everyone
| independently agrees on the same output.
| withinboredom wrote:
| We are saying the same thing. I was pointing out that the
| article missed one of the hardest parts of actually
| implementing this, where your algorithm architecture can
| totally fuck you over if you didn't plan for it. I just
| think it's interesting that they missed pointing it out.
| Either they got it right on the first try or they haven't
| realized the issue with the schema they're proposing.
| jchanimal wrote:
| We handle this in Fireproof with a deterministic default
| algorithm, in addition to having a hash-based tamperproof
| ledger of changes. Fireproof is not SQL based, it is more
| like CouchDB or MongoDB, but with cryptographic integrity.
| Apache 2.0 https://use-fireproof.com
|
| In practice during CouchDB's heyday, with lots of heavy
| users, the conflict management API almost never mattered,
| as most people can make do with deterministic merges.
| philsnow wrote:
| We shouldn't be surprised because the writer works with both
| sqlite and AI but
|
| > Here's a polished section you can insert into your article (it
| fits naturally after the Sync Phase section):
___________________________________________________________________
(page generated 2025-10-13 23:00 UTC)