Server-authoritative, offline-first SQL sync you can operate. Clients keep a real local SQLite database (OPFS in the browser, native SQLite elsewhere), writes go through an optimistic outbox, and one ordered commit log on the server stays the source of truth.

Documentation ·
Quickstart ·
Live demos ·
Benchmarks ·
Blog

bun create syncular-app my-app- Spec-first:- SPEC.mdis normative and- spec/vectors/are golden fixtures; when spec and code disagree, the code changes. Two cores (TypeScript and Rust) are kept in lockstep by an implementation-agnostic conformance suite.
- Test doctrine: loopback in-memory transport for integration scenarios; fault injection at the transport interface; tests wait on explicit readiness signals (sleeps are banned); real-socket tests few and quarantined. See- packages/conformance.
- One good path: the browser persists to OPFS and reports unsupported environments as errors; sync runs over the WebSocket.

| Path | What it is |
|---|---|
| packages/core | Protocol codecs, shared types, vector round-trip |
| packages/server | handleSyncRequest(bytes, ctx)+ storage/auth interfaces (SQLite, Postgres, D1) |
| packages/server-hono,packages/server-workers | Framework bindings (Hono, Cloudflare Workers) |
| packages/web-client | @syncular/client: TS client core on@sqlite.org/sqlite-wasm |
| packages/react | React hooks over the client |
| packages/typegen | Schema IR + TypeScript emitter, named queries (cargo-free) |
| packages/crypto,packages/crdt-yjs | Per-column E2EE primitives, Yjs CRDT mergers |
| packages/testing | @syncular/testkit: in-memory loopback of real server + clients |
| packages/conformance | Scenario runner both cores must pass |
| rust/ | The Rust client core and its C-ABI FFI crate |
| bindings/ | Tauri, React Native, Swift, Kotlin, Flutter |
| apps/docs | The docs site (syncular.dev) |

bun install bun run check # typecheck + lint + test
Read AGENTS.md first. The doctrine in it (spec-first, no
fallbacks, no timers in tests, cross-core parity) applies to human and
machine contributors alike.

On AI assistance: LLMs are welcome for tests, reproductions, benchmarks, docs, and production code. Review, understand, and iterate on everything you submit, and be ready to defend every line; production code gets the strictest review. In syncular's own development, LLM assistance is used mainly for writing tests and iterating over technical concepts, under that same review bar. Low-effort machine-generated PRs, issues, and comments are closed without comment. The full policy and the plain-text docs bundle for agents live at syncular.dev/llms.