Where datadata sits
The local-first community has converged on a fairly standard set of dimensions for describing sync engines (as popularized by the Local-First Landscape). Here is datadata, answered honestly along those lines.
At a glance
Section titled “At a glance”| Dimension | datadata |
|---|---|
| Maturity | Prototype / pre-alpha. Working, actively reshaped, not open source yet. |
| Distribution | TypeScript library (client + server), self-hosted. No hosted service. |
| Data model | Documents — typed JSON with embedded Yjs text. Schemas are documents too. |
| Schema management | Schema documents (optionally authored in TypeScript — typed, no codegen — and upserted at startup) with append-only migrations; documents migrate on next read with write-back; invalid documents flagged, not dropped; optional dynamic runtime schemas (experimental). |
| Authority | Centralized — one server per folder orders all events. |
| What syncs up | JSON Patches + Yjs updates, optionally guarded. |
| What syncs down | Initial snapshot, then patches + Yjs updates. |
| Replication granularity | Per-document subscriptions within a folder; no partial replication inside a document, no cross-folder sync. |
| Data size | Documents (and single events) cap at 1.9 MB in the current backend; model larger data as more documents. |
| Conflict handling | Layered: server ordering + opt-in guards for structure; Yjs CRDT for text; three-way staged previews in sessions. |
| Optimistic updates | Yes — core mechanism, with clean rejection. |
| Offline reads | Whatever the client already holds; no client-side persistence. |
| Offline writes | No. Online-optimistic only; no durable queue or reconnect merge. |
| Local query | Document reads + subscriptions — no query language, no cross-document select/project. An experimental projection layer reshapes a (fully synced) document into ergonomic views; writable lenses are alpha. For queries, the supported pattern is a derived store: project changes into another document or database and query that. |
| Server persistence | SQLite (Durable Object storage) via pluggable adapter; snapshots + append-only event logs (no compaction). |
| Transport | WebSockets; in-process bus for server-side agents, tests, demos. |
| Auth | Token at the door (minted by host app). No built-in authorization rules. |
| Encryption | Transport-level only. No E2E encryption — incompatible with server-side validation as designed. |
| Rich text | Embedded Yjs documents; no presence/awareness yet. |
| Client platforms | Browser + server-side JS. React (Jotai) bindings; devtools panel. |
| AI agents | A design focus: sessions, provenance, in-process clients, agent-writable schemas. |
The one-sentence differentiator
Section titled “The one-sentence differentiator”Everything — user data, schemas, the engine’s own state, staged work — is a document behind one small referential API, with an explicit staging layer (sessions) designed for humans and AI agents proposing changes to shared data.
If those dimensions read like a fit, continue to Compared to other engines; if some of the “No”s above are deal-breakers, When to use it names better-suited engines without hard feelings.