One timeline

More of datadata’s design traces back to one lesson than to anything else. It comes from years of building systems with heavy schema evolution — most recently a headless CMS: a document’s meaning should never be split across histories that move at different speeds.

How meaning gets split

In a conventional stack, what a stored record means lives in at least three places: the data itself, the database schema, and the source code that reads and writes it. Each has its own history — the data’s, the migration log’s, the repository’s — and they are correlated only by deploy timestamps. Answering “what did this document mean when it was written?” becomes archaeology across git history, deploy logs, and migration tables.

Schema evolution widens the cracks. Database changes and code changes never land atomically — there is always a window where new code meets old shapes or old code meets new ones. And some changes leave no trace where the data lives at all: remove a field from a code-defined schema, and the only record of the removal is a commit.

Distribution splits it again

With one central database, you can at least pretend a change happened at a single moment. In a distributed deployment there isn’t even that. datadata runs one isolated store per folder, and a rollout reaches each folder at its own moment, as instances restart. “When did the schema change?” has no global answer — only a per-folder one. Any design that assumes one deploy moment is telling a fiction somewhere.

datadata’s response

Make the per-document event log the only timeline that matters. Three decisions follow directly:

• Schemas are documents. Schema history lives in the same event log as the data it governs. Even TypeScript-authored schemas are upserted into documents at startup — so a code rollout becomes a document write in each folder, and each folder’s log records when the change reached it: the only honest answer an eventually-consistent fleet can give.
• Changes are data, not domain events. A JSON Patch is self-applying; there is no reducer code whose history must stay synchronized with the event log, and history replays identically forever.
• Every event is tagged with its schema version. Any historic version of any document is interpretable with the exact schema it conformed to — in place, or exported to somewhere that has never seen the source code.

What this buys: point-in-time introspection has exactly one place to look, and a folder’s history is portable because it carries its own interpretation with it.

Where the principle stops

Not everything in datadata is timeline philosophy, and it would be suspicious if it were. The session client keeps its changesets in host documents not for the sake of history, but because the real-time, multi-client sync machinery already existed — a document is simply a very convenient place to put staged state that needs to survive reload and converge across authors. Same mechanism, different reason.