Comment by satvikpendem
10 hours ago
Looks interesting, was looking for something like this as currently for Flutter I use Loro via flutter_rust_bridge as the CRDT data store, but it's not SQL so some things like big queries are annoying. How are you handling CRDTs in a SQL database? I thought those were notoriously hard as relational wasn't built for CRDT style syncing?
That’s kinda the tension I wanted to avoid. I’m not trying to make the whole SQL database a CRDT.
CRDTs are opt-in per column. A row can keep normal, queryable fields like project_id, status, and title, while one doc column stores Yjs/yrs bytes. Concurrent edits to that column are merged by the server; normal columns still use versions and explicit conflicts. Flutter uses yrs through the shared Rust core.
The trade-off is that SQL can’t query inside the CRDT document. Anything you need for filtering, joins, or aggregates should remain an ordinary column. That boundary gives you relational queries without giving up CRDTs where they’re really useful.
I’d be interested in your feedback on the Flutter client. I chose a very small C ABI—five hand-written dart:ffi bindings into the Rust core, rather than generating a large FFI surface. The app-specific schema, row types, subscriptions, and typed SQL/SYQL queries are generated from the shared schema IR using syncular generate. I’d love to hear how that feels compared with your flutter_rust_bridge setup.
More detail: https://syncular.dev/concepts-crdt/ https://syncular.dev/platform-flutter/
Got it. Many things I do need to be queryable though, like for example if I'm making a to-do list app the todos need to be queryable, so not sure your approach solves much for my use cases. For the Flutter side it's not too bad using FRB, I'd say AI takes care of a lot of the details.