DaoDB: A Distributed Database Built on Immutable Streams
Imagine a database that doesn't store your current state—it stores all your states. A database where time travel isn't a feature request but a fundamental capability. Where collaboration doesn't require trusting a cloud provider. Where conflicts resolve automatically through causal ordering instead of last-write-wins chaos.
This is DaoDB: a distributed database built on flowing datom streams, where facts are append-only, history is immutable, and your data stays under your control.
The Stream-First Architecture
DaoDB doesn't exist in isolation—it's built on top of DaoStream, a flow through which datoms travel as five-element tuples: [e a v t m]. These tuples represent entity, attribute, value, time, and metadata.
The stream itself doesn't store datoms. They flow through it—some ephemeral and transient, others consumed by applications that choose to materialize them. DaoDB taps into this flow and selectively materializes covered indexes from the datoms it observes.
Every piece of data in DaoDB is a materialized covered index derived from the datom stream. These indexes are append-only and immutable, creating a complete history of all state changes. You're not looking at a snapshot of now—you're looking at the entire timeline of reality since the database began.
Not all datoms in a stream need to be stored. DaoDB selectively consumes what it needs based on query patterns and retention policies. This means different nodes can maintain different views of the same streams—some storing everything, others keeping only recent data or specific attributes.
Understanding the Five-Element Tuple
Every datom follows the same structure: [e a v t m]. This isn't arbitrary—it makes every fact self-describing and independently meaningful.
- e (entity) — The thing being described: a user, a post, a shopping cart
- a (attribute) — The property being asserted: name, color, quantity
- v (value) — The actual data: "Alice", "red", 42
- t (time) — Transaction ID, monotonic within this stream (not globally ordered across streams)
- m (metadata entity ID) — References a metadata entity containing causal relationships, branching info, encryption context, or interpreter-specific data. Used to determine causality across different streams, since
thas no meaning outside its originating stream
You can query any datom without needing to understand the entire database schema. Schemas evolve naturally as new attributes are added—no migrations, no downtime, no breaking changes. This is schema-on-read: define schemas when you query, not when you write.
Local-First, Quantum-Inspired Synchronization
DaoDB is fundamentally local-first. When isolated, each device maintains its own complete tuple store with stream-local transaction IDs advancing monotonically. But when devices entangle into a synchronization group, something profound happens: one leader establishes event ordering, imposing a single monotonic sequence across the entangled streams.
Each device holds only a partial view of the whole state. Together, all devices in the entanglement group collectively maintain the complete database state. This is quantum unitarity in a distributed system—the total information is preserved across the system, but no single observer possesses the complete state. Within the entanglement, the leader coordinates ordering, yet t values remain scoped to their streams—cross-stream causality is determined via m metadata.
This isn't just metaphor. When two devices with divergent states synchronize, they experience what DaoDB calls wave function collapse—a conflict resolution moment where causal ordering determines which facts persist. Learn more in our post on how DaoDB implements Relational Quantum Mechanics.
Unlike cloud databases that force you to trust a central server, DaoDB keeps custody of your data locally. You choose which streams to expose and who can read them. Collaboration happens through shared streams, not by surrendering control to a third party.
Three Core Properties
1. Immutable History
Every datom is append-only. Nothing is ever deleted or overwritten. Query any point in time. Undo becomes trivial—just rewind the transaction log. Audit trails are built-in, not bolted on. You don't need to implement soft deletes or maintain shadow tables. Time travel is the default mode.
2. Distributed by Design
DaoDB syncs across devices using CRDTs and causal ordering. Conflicts resolve automatically through the metadata embedded in each datom's m component. No central coordination needed. No master node. No split-brain scenarios requiring manual intervention.
3. Schema-on-Read
Define schemas when you query, not when you write. Add new attributes without migrations. Multiple interpreters can view the same datoms differently. One application's :user/email is another's :identity/contact-method—the facts remain the same, only the interpretation changes.
Querying with Datalog
DaoDB implements Datomic's syntax of Datalog—a declarative query language built on Horn clauses, fixed-point semantics, and guaranteed termination. Queries are expressed as EDN data structures, making them homoiconic (code as data) and composable.
;; Find all entities with a name attribute
(d/q '[:find ?e ?name
:where [?e :person/name ?name]]
db)
;; Time travel: query the database as of a specific transaction
(d/q '[:find ?e ?email
:where [?e :user/email ?email]]
(d/as-of db tx-id))
;; Audit: find what changed between two points in time
(d/q '[:find ?e ?a ?v
:where [?e ?a ?v]]
(d/since db tx-id))Because indexes are materialized from immutable streams, queries naturally support temporal access. Ask what the world looked like at any point in history. Track how entities evolved over time. Audit who changed what and when. These aren't special features—they're inevitable consequences of the architecture.
Learn more about what makes Datalog Datalog and why Datalog makes every optimization queryable.
Multiple Interpreters, One Stream
DaoDB provides the database view: structured queries over flowing facts. But other applications interpret the same streams differently:
- DaoFlow renders datom streams as reactive user interfaces
- Shibi interprets them as economic signals and value flows
- Yin agents process streams as computational primitives
The same facts, flowing through the same streams, materialized into different forms by different interpreters. This is the power of separating representation from interpretation—a theme explored in our post on semantics, structure, and interpretation.
Why Streams Matter
Traditional databases ask: What is true now? DaoDB asks: What has ever been asserted? This shift from state to stream unlocks capabilities that are difficult or impossible in conventional systems:
- Offline-first applications that sync seamlessly when reconnected
- Collaborative editing without operational transforms
- Compliance and audit trails without additional infrastructure
- Experimentation with
as-ofandwhat-ifqueries - Gradual schema evolution without coordination
When you model the world as an immutable log of facts, time becomes just another dimension you can query. The database doesn't lose information—it accumulates it. Your application doesn't manage state—it observes history.
Getting Started
DaoDB is part of the Datom.World ecosystem. To begin exploring:
- Understand how DaoStream works
- See how Yin agents process DaoDB streams
- Visualize your data with DaoFlow
- Read about streaming datoms with transducers
DaoDB isn't just a database—it's a different way of thinking about data, time, and truth. It's immutable by default, distributed by design, and yours to control.
Welcome to the stream.