When to use it (and when not)

This page is the short, honest version. For the per-feature detail, see Where datadata sits and Limitations.

A good fit today

• Collaborative document apps — multiple people editing structured documents and rich text in real time, with instant local feedback.
• Human + AI co-editing — an agent stages changes in a session, a human reviews a three-way preview and commits. This is the workflow datadata is being honed against.
• Evolving domains — schemas are documents with their own migration history, so the data model can change while the app is running.
• Apps already on Cloudflare — the production backend is a Durable Object per folder with SQLite storage; if that’s your platform, deployment is natural.

Not a fit (today)

• Offline-first apps. datadata is online-optimistic: writes apply locally and instantly, but there is no durable offline queue or sync-on-reconnect story yet.
• Apps needing fine-grained permissions. Authentication is delegated to the host app; per-document authorization rules don’t exist yet.
• Large datasets. A folder is the sync unit and lives in one Durable Object; there is no partial replication within a folder, documents cap at 1.9 MB, and there is no event-log compaction yet.
• Tabular, query-shaped data. Sync is whole-document — you can’t select or project parts of documents, and there is no query language. The supported pattern is a derived store (listen to document changes, project into another document or database, query that), but if your data is fundamentally tabular, a database-replication engine is the better match — see Compared to other engines.
• Peer-to-peer or end-to-end-encrypted designs. datadata is deliberately server-authoritative.

Not a fit (by design)

Some of the above will change; the server-authoritative model won’t. If you want decentralized authority or CRDTs for all data (not just text), engines like Automerge or Jazz are designed for that — see Compared to other engines.