Syncular 0.5.0 – Offline-first SQL Sync with TypeScript and Rust Cores

Overview

Syncular 0.5.0 provides offline-first SQL synchronization where each client maintains a real local SQLite database and writes are persisted through an optimistic outbox before being validated and ordered by a server-authoritative commit log.

The project is self‑hosted, pre‑1.0, and does not offer a managed service or peer‑to‑peer mode. Native packaging maturity varies across ecosystems.

Architecture

Clients store data in a genuine SQLite database: sqlite‑wasm backed by the Origin Private File System (OPFS) in browsers, and native SQLite elsewhere. All writes are applied locally and simultaneously recorded in a durable outbox within the same transaction. The server maintains a single ordered commit log that serves as the source of truth, validates incoming changes, and resolves them using explicit scopes defined in the application backend.

Protocol and Spec‑first Approach

Syncular’s protocol is specified independently of its implementations in SPEC.md, with golden byte vectors in spec/vectors/ serving as the canonical reference. When the specification and the code diverge, the code is adjusted to match the spec. The protocol draft is named SSP2 and includes a canonical binary encoding.

Two independent cores—one written in TypeScript and the other in Rust—are kept in lockstep by an implementation‑agnostic conformance suite that runs 95 scenarios against both implementations.

Client Cores and Bindings

The TypeScript core powers the web client (@syncular/client) which runs on @sqlite.org/sqlite-wasm. The Rust core is exposed through language bindings for Swift, Kotlin, Flutter, React Native, Tauri, plain Rust, and a small C API.

These bindings allow developers to integrate Syncular into native mobile and desktop applications while sharing the same sync logic.

Key Features

  • Realtime synchronization over WebSocket with resumable bootstrap segments for efficient initial sync.
  • Explicit conflict evidence is recorded to help applications understand and resolve divergent changes.
  • Authorization revocation and local purge enable removal of a user’s rights and deletion of their data from the client.
  • Windowed replicas allow clients to synchronize only a subset of data based on defined ranges.
  • Binary large objects (blobs) are supported alongside regular SQL data.
  • Optional CRDT columns are available, backed by Yjs‑based mergers located in the packages/crdt-yjs directory.
  • Per‑column encryption provides end‑to‑end confidentiality for selected fields.
  • Typesafe query generation is provided for five languages via the typegen package, which emits schema‑aware helpers from a shared intermediate representation.

Development Practices

Syncular follows a spec‑first methodology: the specification is the arbiter of correctness. The test doctrine mandates loopback in‑memory transport for integration tests, fault injection at the transport layer, and explicit readiness signals—sleeps are prohibited in tests. Real‑socket tests are limited and quarantined.

The repository encourages “one good path”: browsers persist to OPFS and report unsupported environments as errors, while synchronization occurs over WebSocket.

Regarding AI assistance, the project’s contribution guidelines state that large language models are welcome for writing tests, reproductions, benchmarks, documentation, and production code, provided that every line is reviewed, understood, and ready to be defended; low‑effort machine‑generated contributions are closed without comment.

Deployment and Limitations

As of the latest release (v0.5.0, July 14 2026), Syncular remains pre‑1.0. It is designed for self‑hosted deployment only; there is no hosted service or peer‑to‑peer mode offered. The README notes that native packaging maturity still varies by ecosystem, meaning some language bindings may be more mature than others.

Community Questions and Author Responses

  • CRDT handling in SQL: The author notes that Syncular offers optional CRDT columns, implemented via Yjs mergers, allowing applications to opt‑in to conflict‑free replicated data types for specific fields while keeping the rest of the data model relational.

  • Conflict resolution: Instead of a automatic conflict‑resolution algorithm, Syncular records explicit conflict evidence, leaving the resolution policy to the application developer.

  • Comparison to PowerSync: The author did not provide a direct comparison; the project’s documentation does not mention PowerSync.

  • Browser storage eviction: The author confirmed that pending writes reside in the OPFS‑backed SQLite database but did not specify whether the library requests persistent storage or warns users about possible eviction of the outbox.

  • Use of LLMs: The author stated that during Syncular’s development, LLM assistance was primarily used for writing tests and iterating over technical concepts, under the same strict review bar applied to all contributions.

These points are drawn directly from the repository README, the release notes, and the author’s comment on the Hacker News post.

Conclusion

Syncular 0.5.0 delivers a spec‑driven, offline‑first SQL sync solution with dual TypeScript and Rust runtimes, a durable outbox model, and a suite of features ranging from encrypted columns to optional CRDT support, all aimed at developers who need self‑hosted, realtime‑capable synchronization without relying on a managed service.

Sources