This resonates a lot. We ran into the exact same "5 systems" problem building a real-time collaboration tool. You end up with Postgres for persistence, Redis for pub/sub, some kind of CRDT layer, a separate search index, and then a caching layer on top.
The SQL-first approach is interesting because most of these unified solutions sacrifice query flexibility. Being able to just write normal SQL but still get real-time updates sounds like the best of both worlds honestly.
Curious about the conflict resolution strategy when multiple clients write to the same row simultaneously. Is it last-write-wins or something more sophisticated?
Appreciate that — that’s exactly the pain point I kept running into too. You start with “just store some messages,” and suddenly you’re operating a database, cache, pub/sub system, search index, and coordination glue.
That’s really the motivation behind KalamDB: keep the SQL model developers already know, but make real-time subscriptions part of the database itself instead of something you bolt on later.
For conflicts, KalamDB follows a simple MVCC model where the latest change wins. One design choice that helps a lot is isolating each user’s data, every user effectively has their own tables/tenant space. Because writes from different users don’t hit the same rows, it removes a large class of conflicts in the first place.
Looking forward, especially for offline-first use cases, I’m interested in moving closer to CRDT-style conflict resolution. That could mean merging columns or applying diffs when concurrent edits happen. I haven’t finalized the design yet, but there are some good ideas from existing systems that could fit well here.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
This resonates a lot. We ran into the exact same "5 systems" problem building a real-time collaboration tool. You end up with Postgres for persistence, Redis for pub/sub, some kind of CRDT layer, a separate search index, and then a caching layer on top.
The SQL-first approach is interesting because most of these unified solutions sacrifice query flexibility. Being able to just write normal SQL but still get real-time updates sounds like the best of both worlds honestly.
Curious about the conflict resolution strategy when multiple clients write to the same row simultaneously. Is it last-write-wins or something more sophisticated?
Appreciate that — that’s exactly the pain point I kept running into too. You start with “just store some messages,” and suddenly you’re operating a database, cache, pub/sub system, search index, and coordination glue.
That’s really the motivation behind KalamDB: keep the SQL model developers already know, but make real-time subscriptions part of the database itself instead of something you bolt on later.
For conflicts, KalamDB follows a simple MVCC model where the latest change wins. One design choice that helps a lot is isolating each user’s data, every user effectively has their own tables/tenant space. Because writes from different users don’t hit the same rows, it removes a large class of conflicts in the first place.
Looking forward, especially for offline-first use cases, I’m interested in moving closer to CRDT-style conflict resolution. That could mean merging columns or applying diffs when concurrent edits happen. I haven’t finalized the design yet, but there are some good ideas from existing systems that could fit well here.