Overview#

I have spent my career with systems where incorrect data can cause real-world harm. These systems must record who changed what, when, and why.

At production scale, that record often becomes expensive, slow, and difficult to trust. Teams then must select between delivery speed and complete history.

Stardust is the most important work of my career. It lets teams focus on unique project knowledge without losing information.

Its design comes from at least a decade of experiments with entity-component-system ideas for databases. Many approaches failed, and those failures shaped the current design.

Delaney Gillilan, creator of Stardust

Move quickly without losing history#

Most projects begin with current state, but separate tools appear as projects grow. These tools collect audit logs, run background work, send messages, or create backups. Each tool adds another account. At scale, those accounts can disagree about identity, time, or authority.

Stardust starts with one requirement: speed of change must not erase explanation. A trustworthy value includes the change and the time behind its current state. Projects can add structure to revised knowledge without destroying the information that explains the current state.

A data engine for project knowledge#

Game developers use engines so they do not rebuild common game systems for each project. They can spend more time on what makes their game unique. The same idea applies to project knowledge. Each project owns its domain meaning.

One consistent foundation supplies common data concerns. That foundation records changes while keeping their history. It also derives answers, keeps them live, runs controlled automation, manages binary data, and supports recovery. The shared value model gives different languages and systems a common baseline. A project can unite its systems without making one programming language the center.

Theory that survives production#

A good theory must continue to work under production load. An authoritative source that is too slow creates pressure to make faster copies. Each copy can become a competing authority.

Performance is part of trust rather than an optional improvement after correctness. Correctness, performance, and operational safety form one engineering problem. Each boundary must explain changes, operate under load, and support recovery after loss.

Theory articles#

Read the articles in order, or select one:

• Standards establish a common language between people, tools, and systems.
• FUSE presents the database through the file interface that operating systems and tools already understand.
• LSP gives editors and agents the same interface for direct actions and change subscriptions.
• Patches explain why thinking in terms of intent differs from thinking in terms of events.
• Reification turns operations, definitions, and context into queryable facts.
• Fields give project knowledge stable names without requiring a complete field model.
• Components retain useful types within an open value model.
• Schemas apply selected definitions of correctness without closing the full ontology.
• Queries derive answers, and live queries keep those answers current.
• Mutations connect a selection to a change, and live mutations run it inside Stardust.
• Binaries separate large payloads without separating them from recovery.
• Code keeps Expressions and Macros as data.
• Eventbus supports live coordination without confusing messages with durable knowledge.
• Blackholes reconcile complete history with necessary removal.
• Backups make survival after loss part of the data design.
• Inspirations credit the projects that informed Stardust's design.