Limitations
Each limitation is tagged honestly:
- By design — a consequence of the model; won’t change.
- Not yet — wanted, understood, unbuilt.
- Open question — we don’t know the right answer yet; see Open questions.
| Limitation | Status | Notes |
|---|---|---|
| No hard deletion (purge) | Not yet | Deletion is soft: doc:delete tombstones a document (restorable via doc:restore, listed in sys:trash) but its append-only history is retained forever. Purging — destroying a deleted document’s events and Yjs state for storage reclamation or right-to-erasure — is designed (storage reserves purged_at) but unbuilt. |
| No offline writes / reconnect merge | Not yet | datadata is online-optimistic. Short interruptions resume; a real offline period has no durable queue or replay. The hardest “not yet” on the list. |
| No client-side persistence | Not yet | The client holds state in memory; a reload refetches. Local persistence would also be the foundation for offline reads. |
| No authorization rules | Not yet / open question | Connections are authenticated (host-minted token per folder); what a user may do inside a folder is the application’s problem. Whether authorization belongs in the engine (schema-declared rules?) is open. |
| No event-log compaction | Not yet | Document and Yjs logs are append-only and unbounded; doc:get-events is unpaged. The most concrete scaling gap. See Storage & event log. |
| Documents cap at 1.9 MB | By design (for now) | The current backend caps a document (and a single event) at 1.9 MB — under the Durable Object SQLite value limit. Whole-document sync makes huge documents the wrong shape anyway: model large data as more documents. |
| No queries across documents | By design (for now) | There is no query language — no select/project over multiple documents. The supported pattern is a derived store: listen to document changes and project them into another document (or another database), then query that. |
| No partial replication within a folder | By design (for now) | Subscriptions are per-document; a document syncs whole. Folder = authority unit, document = sync unit. |
| No cross-folder sync or federation | By design (for now) | A folder is one server’s world; nothing spans folders. |
| No P2P, no decentralized authority | By design | The server-authoritative model is the point — see Design decisions. |
| No E2E encryption | By design | Server-side validation requires the server to read the data. |
| No presence/awareness | Not yet | Yjs awareness (cursors, selections) isn’t wired through the event bus; only document state syncs. |
| Dynamic runtime schemas are experimental | Not yet (hardening) | The static-registry path is solid; clients reactively adopting sys:schema:* changes at runtime is the least battle-tested area. |
| One changeset per host document | Open question | Sessions don’t multiplex named changesets per host yet — deliberately deferred until the apps demand it. |
| Projections are per-document, read-mostly | Experimental / open question | A projection layer reshapes a document into more ergonomic views — but it operates on the full synced document (it is not partial sync), and writable lenses are very alpha. Whether projections should be writable at all is open. |
| JS/TS only | By design (for now) | datadata is a TypeScript library on both sides of the wire. |
If one of these is the thing you came to check — that’s the page working as intended. If you think one of the classifications is wrong, that’s a conversation worth having.