TaxisDB

Welcome to TaxisDB 👋

TaxisDB is a metamodel-driven, reflective, temporal, immutable, fact-oriented database engine implemented on top of YottaDB.

TaxisDB treats both domain facts and the model that describes those facts as first-class data. Rather than representing information primarily as mutable rows or documents, it represents changes as immutable assertions and preserves their transaction history.

Temporal

In TaxisDB, time is a fundamental dimension of the database model rather than merely an external audit mechanism. TaxisDB preserves the evolution of information and allows the database to reconstruct the state of its facts at earlier points in transaction time.

This enables:

• Historical reconstruction
• Time-based reasoning
• Audit history
• State evolution tracking
• Reproducibility of previous database states

It is important to distinguish transaction time from valid time:

• Transaction time: when the database learned or recorded a fact.
• Valid time: when a fact is considered true in the modeled domain.

A database that tracks both is generally described as bitemporal. TaxisDB currently implements transaction time. Valid time is left to the domain model and can be represented as a schema-level property where required.

Immutable Facts

In TaxisDB, facts are asserted, not overwritten. Once recorded, a fact is not modified or deleted in place. When the state of an entity changes, the database records new assertions while preserving the previous ones. History therefore forms part of the database itself rather than being reconstructed from an external audit log.

This provides several important properties:

• Complete history preservation: previous assertions remain available.
• Deterministic state reconstruction: historical database states can be reconstructed from the recorded facts.
• Auditable change history: changes are represented explicitly as a sequence of assertions.
• Non-destructive updates: there is no conventional in-place update operation that silently replaces previous information.
• Stable identity: entities retain their identity independently of the attributes asserted about them.

Immutability does not mean that the database is static. It means that change is represented by additional facts rather than mutation of existing facts.

Fact-Oriented Model

The fundamental unit of information in TaxisDB is a fact, or assertion, rather than a mutable row or document.

Conceptually, facts can be represented using an EAVT structure:

Entity → Attribute → Value → Transaction Time

This places TaxisDB in the same broad family of ideas as EAV systems, Datalog, RDF-style assertions, and Datomic’s datom model, while retaining its own storage and modeling semantics.

Because facts are immutable, entity identity must exist independently of the changing attributes asserted about an entity. An entity therefore represents a stable subject to which successive facts can be attached over time.

The result is a database model centered on assertions about entities and their relationships, rather than on records whose fields are repeatedly overwritten.

Reflective / Metamodel-Driven

TaxisDB represents its own model, including entity types, attributes, relationships, and constraints, as data.

The same fact-oriented mechanisms used to represent application data are therefore also used to represent the model describing that data:

Database
 ├── Model data     (what the structure is)
 └── Domain data    (what the application knows)

This makes the database reflective. Clients can inspect the model programmatically and discover how data is structured without requiring a completely separate schema description.

It also makes model evolution an explicit part of the database’s data model. Changes to the model can be represented using the same underlying assertion mechanisms used for changes to domain data.

This does not imply that every schema change is automatically migration-free. The operational guarantees of a model change still depend on the particular change and on TaxisDB’s implementation. The important distinction is conceptual: the model is itself represented inside the database rather than existing only as external metadata.

YottaDB as Substrate

TaxisDB is implemented on top of YottaDB, which provides the underlying persistence and transaction infrastructure.

YottaDB supplies capabilities including:

• Durable persistent storage
• ACID transactions
• Concurrency control
• Journaling and recovery
• Replication
• Hierarchical global variables

Its serverless architecture allows multiple independent operating-system processes to access the same database directly, without requiring a database daemon or network protocol between the application and storage layer. Coordination is handled by YottaDB’s transaction, locking, and shared-memory mechanisms.

This allows TaxisDB to focus on logical database semantics, including facts, entities, temporal state, metamodels, reflection, and data access, while delegating the lower-level concerns of durable state management to a mature, battle-tested transactional database engine.

At the same time, YottaDB’s hierarchical globals remain directly inspectable and operationally accessible. This creates a clear separation of concerns:

flowchart TB
    T["<b>TaxisDB</b><br/>Facts • Entities • Metamodel<br/>Constraints • Identity Resolution<br/>Assertions • Retractions • History<br/>Semantic Vocabulary • Reflection<br/>Temporal Semantics • Logging<br/>Database APIs"]

    Y["<b>YottaDB</b><br/>Persistence • Transactions<br/>Locking • Journaling • Recovery<br/>Replication • Global Variables"]

    T -->|"Logical database semantics"| Y
    Y -->|"Durable state management"| T

    classDef bigTitle font-size:16px,font-weight:bold;
    class T,Y bigTitle;

YottaDB provides the durable state-management substrate; TaxisDB defines the database semantics on top of it.

For a deeper look at the ideas behind TaxisDB and substrate architecture, read our article Every Database Had Its Own Storage Engine — Then Came Substrate Architecture.

TaxisDB Project