HN Debrief

Show HN: Syncular – offline-first SQL sync with TypeScript and Rust cores

  • Developer Tools
  • Open Source
  • Infrastructure
  • Programming

Syncular is an open source framework for building offline-first apps around a local SQLite database on every client. The author says writes land locally first, go into a durable outbox in the same transaction, then get validated and ordered by a server-authoritative commit log. The project ships TypeScript and Rust cores, exposes the Rust core to multiple client platforms, and layers in generated typed queries, resumable bootstrap, blobs, optional CRDT columns, per-column encryption, and a written protocol spec. It is still pre-1.0, self-hosted only, and not trying to do peer-to-peer.

If you are evaluating offline-first infrastructure, treat Syncular as a serious protocol-and-runtime attempt rather than a drop-in solved layer. The next thing to verify is not the benchmark chart but whether its conflict APIs, bootstrap behavior, and client storage guarantees match your actual data model and platform constraints.

Discussion mood

Interested but skeptical. People liked the ambition and the clear appetite for offline-first tooling, but confidence was held back by thin conflict-resolution docs, questions about browser storage durability, and visible concern that the project and documentation lean heavily on LLMs.

Key insights

  1. 01

    Row-level conflicts are too weak

    For real applications, conflict handling needs to preserve invariants that span multiple rows or an entire transaction. A per-row API leaves the app guessing about intent and missing the full local-versus-server picture, which makes it easy to converge on data that is still internally wrong.

    Model a few ugly concurrent edit cases before adopting this. If your correctness rules cross row boundaries, ask for transaction-level conflict context or expect to build a lot of merge machinery yourself.

      Attribution:
    • jmull #1 #2
    • pettijohn #1
  2. 02

    CRDT columns help only at the edges

    The hybrid design draws a hard line between relational data and collaborative document data. That keeps SQL queries, joins, and aggregates fast and normal, but anything stored as a Yjs or yrs blob becomes opaque to the database, so the approach stops helping once the fields users edit concurrently are also the fields the product needs to query.

    Map your query surface before getting excited about CRDT support. If search, filtering, or analytics depend on concurrently edited fields, this architecture may force awkward duplication or give you little benefit.

      Attribution:
    • quambo #1
    • satvikpendem #1 #2
  3. 03

    The real comparison is stack ownership

    The useful distinction from PowerSync is not just performance. It is how much of the sync contract the framework takes responsibility for. Syncular aims to own commit ordering, auth scopes, replay, revocation, bootstrap, and generated client APIs instead of acting mainly as downstream replication plus an upload queue. That is a bigger promise and a bigger maintenance surface.

    Choose based on how much sync logic you want your own backend to keep. A more opinionated system can remove glue code, but it also ties you more tightly to its protocol and failure model.

      Attribution:
    • quambo #1
    • nerder92 #1
  4. 04

    Bootstrap latency shapes the whole UX

    One builder with a similar architecture said the hardest problem was keeping first sign-in responsive with a large database. Their solution was on-demand materialization and even multiple local databases to avoid writes stalling during heavy sync. That adds weight to the author's emphasis on bounded bootstrap and durable local queues. Initial sync is not an edge case. It is the moment users decide whether the app feels instant or broken.

    Test first-run and re-login with production-scale data early. If bootstrap blocks interaction or starves local writes, the offline-first story will fail before conflict resolution ever matters.

      Attribution:
    • dools #1
    • quambo #1
  5. 05

    Browser persistence is still a platform risk

    Using SQLite in OPFS gives the browser a real local database, but it does not guarantee the data survives storage eviction. If unsynced writes live only in that local outbox, teams need a plan for requesting persistent storage or warning users that pending changes can disappear under browser pressure.

    Do not treat browser-local durability as solved because the API is modern. Add eviction testing and product behavior for lost local state before promising offline guarantees on the web.

      Attribution:
    • elsaicequeen #1

Against the grain

  1. 01

    LLM-written docs do not prove weak code

    The README's "vibecoding" tone made some people dismiss the project on sight, but the author drew a line between AI-assisted documentation and the underlying design work. Given the protocol spec, conformance scenarios, and multi-language cores described in the repo, the more useful question is whether the implementation holds up under tests, not whether the prose sounds machine-polished.

    Ignore the style tells and inspect the artifacts that are harder to fake. Read the spec, tests, and failure cases before writing the project off or trusting it.

      Attribution:
    • quambo #1
    • ShinyLeftPad #1
  2. 02

    Offline-first is not nostalgic anymore

    The Lotus Notes comparison was not a joke about old software. It was a reminder that products still win today by feeling local and resilient when competitors treat offline mode as an afterthought. Obsidian versus Notion was the concrete example people reached for. The user benefit is immediate enough that old ideas are becoming current again.

    If your product still depends on perfect connectivity, that is now a product weakness, not just an engineering compromise. Offline behavior can be a competitive feature even when sync remains messy under the hood.

      Attribution:
    • kello #1
    • quambo #1
    • chrisweekly #1

In plain english

bootstrap ↩
The initial process of downloading enough data to bring a new client into sync.
commit log ↩
An ordered record of accepted changes that systems use to replay, replicate, or audit state updates.
CRDT ↩
Conflict-free Replicated Data Type, a data structure designed so multiple copies can be edited independently and later merged automatically without conflicts.
offline-first ↩
A software design approach where the app is built to work locally without network access and syncs changes later.
OPFS ↩
Origin Private File System, a browser storage API that gives web apps private file-like persistent storage.
PowerSync ↩
A sync product that keeps local databases in sync with a backend, often used for offline-capable apps.
Rust ↩
A systems programming language focused on performance and memory safety.
SQLite ↩
A small embedded SQL database engine often stored in a single local file and used inside apps rather than as a separate server.
TypeScript ↩
A typed programming language that compiles to JavaScript and is commonly used for web and server development.
Yjs ↩
A popular CRDT library for building collaborative editing features such as shared text or documents.
yrs ↩
A Rust implementation of the Yjs CRDT model.

Reference links

Project docs and spec

Benchmarks and adjacent tools

  • offline-sync-bench
    Benchmark harness cited by the author when comparing Syncular with PowerSync
  • DuckDB Quack
    Suggested as another relevant local-first or sync-related project to look at

Community and ecosystem

  • localfirst.fm
    Suggested as a community resource for people working on local-first software
  • lofi.so
    Suggested as another local-first community resource

Example apps

  • Benko
    Shared as an example app built with a similar optimistic local-write and sync architecture