Home / Platform

A value is stored once.
Everything else is a consequence.

In a relational database a value is a cell — the string CU1061 appears in the customer table once and in the orders table five more times, six independent copies that happen to spell the same thing. In AtomicDB a value is an item, stored once per concept, and every record mentioning it holds an association to that one item.

Concepts, not columns Items, not cells Associations, not foreign keys Read-time reconstruction
Data consolidation, in motion

Three systems in.
One item per value out.

An illustration: a customer, a country and a product, copied across a CRM, an ERP and a billing system. Watch each copy resolve to a single item in the AtomicDB grid, and each record keep an association to it — consolidation without a pipeline or a target schema.

Four words, and you have the whole model

The store has no tables

🏷️

Concept

What a column means — CUSTOMER ID, COUNTRY, FUEL. The concept carries the meaning, which is why there is no semantic layer to maintain separately.

the definition
⚛️

Item

One distinct value under a concept. CU1061 exists exactly once under CUSTOMER ID, no matter how many records mention it.

stored once, always
🔗

Association

A record holding an item. Six orders mentioning that customer hold six associations to one item — so the relationship is present in the store the moment the data is.

the edge that already exists
🗂️

Knowledge Area

The scope boundary. Models live inside knowledge areas, grouped into quadrants, and a question can be confined to the areas you tick — all the way down through reasoning.

scope is a correctness control
Interactive

Click a value.
Watch the join already be there.

Three systems from different parts of a business. Nobody declared a key between them. Select any value below and every record pointing at that one item lights up — across all three.

Value index · concept “CUSTOMER ID”
selected — associations 0 systems reached 0
Items under this concept — stored once each
No foreign key was declared, and no JOIN … ON was written. Testing whether two records are related is an identity comparison — do they point at the same item — not a string comparison.
How a record set is reconstructed

Fold, then fill to a fixpoint

The unified view is computed when you read it, in two passes. Step through them.

Read-time reconstruction

Four records from three systems, each holding only the columns its own system knows about.

A row never re-joins a dataset it already carries — which is what stops two orders that happen to share QUANTITY = 3 from being treated as related. The fold repeats until nothing changes, so a link discovered late still pulls in the attributes of a dataset consumed early.
The structural consequence

Two reorganisations,
and neither is needed

A warehouse restructures information twice: once on the way in, so heterogeneous sources conform to a load contract, and once on the way out, so the conformed data is shaped into a dimensional model an analyst can query.

Both are artefacts of storing values as cells in tables. A store that holds values as shared, addressable items does not need either one.

The full comparison →

Upstream, in a warehouse

  • Conformed keysCustomer identity in the CRM reconciled with billing; a surrogate key minted and a mapping table maintained forever.
  • A landing schemaTarget types, nullability and partitioning decided — then kept in sync with a source you do not control.
  • A load contractWhat arrives, in what window, with what completeness guarantee, and what happens when it does not.

Upstream, in AtomicDB

  • Nothing to conform toThere is no destination schema, so there is no schema to conform to. A source is ingested with the columns it has.
  • Source structure preservedA model ingested from a CSV keeps that CSV's columns. No conformed intermediate representation to design first.
  • Source systems untouchedNo CDC agent to install, no schema to freeze, no replication contract.
What actually runs

One engine, and the
engines that read it

1

The AtomicDB engine

Pure C, one process. Holds the association hierarchy in memory and the row store beneath it. Session-gated on every read and write.

2

The ledger

Append-only, CRC-chained. Data events in sequence; administrative events in a separate write-only audit store. Corrections retire rather than overwrite.

3

ATLAS

A separate pure-C process that reads the knowledge base read-only, reasons over it in memory, and writes conclusions back into its own two areas.

4

The sidecars

Ask, JADE, FIPA, MESA, Quantum, speech in and out — each a small native process on loopback, each reading the same store through the authenticated path.

Everything is loopback-only by default. The engine, the reasoning engine, the local language model, speech-to-text and text-to-speech all run on one machine and listen only on the loopback interface. No API keys, no vendor, no per-question cost, and no bytes leaving the building — which is why payroll questions can be asked without telling anyone.
Quadrants and knowledge areas
Quadrants → knowledge areas → models → concepts
Ingestion graph
Ingestion — sources land in their own shape
Stated plainly

The real limits

A document that omits them is not useful for a decision. These are measured properties, not caveats.

AtomicDB runs as one engine process per installation, not a shared-nothing cluster. Vertical scaling is today's growth path; a multi-server layout with pooled memory — pictured in the Mapper closing film — is a design on the roadmap, not a shipped feature. Separate installations already work together through federation and the Virtual View, but there is no horizontal scale-out comparable to an MPP warehouse. An organisation whose problem is genuinely “scan five petabytes quickly” should buy a warehouse.
The association graph is resident, which is what makes traversal fast and what bounds capacity. Sizing analysis for a 10-million-record, 75-attribute workload places the hierarchy in the 35–45 GB range — comfortable on a 128 GB host — with the practical constraints being checkpoint I/O and startup index rebuild time rather than query performance.
Reads return at most 500 records per request, with the true total reported alongside. Clients page through until they hold the complete set; where a ceiling is reached it is stated on screen rather than quietly reconstructing from part of the data. This is a deliberate bound, not a limit on the data.
Export to CSV and Excel is built in and the engine exposes an HTTP API, but there is nothing yet resembling the connector ecosystem of a major platform. Native Tableau / Power BI / Looker connectors represent an integration surface that took those vendors years to build.
Relationships come from shared values. Two datasets that genuinely share no value cannot be related by the Mapper, however obviously they belong together to a human reader. The remedy is the same as the rest of the procedure — place a concept both datasets populate onto one grid object — but it is a real constraint and it should be understood before adoption.
SQL is the most widely held data skill in existence and hiring for a warehouse stack is straightforward. The associative model asks people to learn a different way of thinking about relationships. That is a genuine adoption cost.

See it do something

The model is the argument, but the Mapper is where you watch it pay off.

Merge five datasets → Correct a dirty value Talk to us