Show HN: Syncular – offline-first SQL sync with TypeScript and Rust cores
21–30 of 44 posts
Re: Show HN: Syncular – offline-first SQL sync with TypeScript and Rust cores
#22Hi HN! I’ve been circling this problem for a long time. In 2019 I built an offline-first datastore called debe. It used CRDTs and multi-master replication and never became something I could confidently ship. It did teach me that convergence is only a small part of sync. The difficult parts are durable writes, authorization changes, lost acknowledgements, schema upgrades, bounded bootstrap, and explaining what happene…
Re: Show HN: Syncular – offline-first SQL sync with TypeScript and Rust cores
#23No mention of conflict resolution? I suspect it's far too naive to be useful for anything real.
Re: Show HN: Syncular – offline-first SQL sync with TypeScript and Rust cores
#24No mention of conflict resolution? I suspect it's far too naive to be useful for anything real.
Re: Show HN: Syncular – offline-first SQL sync with TypeScript and Rust cores
#25Looks 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?
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/
Re: Show HN: Syncular – offline-first SQL sync with TypeScript and Rust cores
#26I wish there was an established way to build local first software with a robust syncing in the background, either P2P or to a server. I feel projects like this for local first and projects like Iroh for connectivity over NAT and through firewalls need to come together more. It would be could to have a drop in framework for this.
Re: Show HN: Syncular – offline-first SQL sync with TypeScript and Rust cores
#27Hi HN! I’ve been circling this problem for a long time. In 2019 I built an offline-first datastore called debe. It used CRDTs and multi-master replication and never became something I could confidently ship. It did teach me that convergence is only a small part of sync. The difficult parts are durable writes, authorization changes, lost acknowledgements, schema upgrades, bounded bootstrap, and explaining what happene…
Very interesting, have you experimented with getting it working with Crux in Rust?
Re: Show HN: Syncular – offline-first SQL sync with TypeScript and Rust cores
#28I wish there was an established way to build local first software with a robust syncing in the background, either P2P or to a server. I feel projects like this for local first and projects like Iroh for connectivity over NAT and through firewalls need to come together more. It would be could to have a drop in framework for this.
Re: Show HN: Syncular – offline-first SQL sync with TypeScript and Rust cores
#29Be warned, AI Slop ahead