Every database answers a question by looking for something. AtomicDB answers it by going to where the answer already is. This page explains why that single difference removes the join, the index, the warehouse and most of the GPU — in plain language, with the measured figures beside it.
Ordinary databases store a value as a cell. The same customer number written in six orders is six unrelated copies of a string, and a join compares those strings again every time someone asks.
AtomicDB stores each distinct value once, as an item, under the concept it belongs to — what a column means, such as CUSTOMER ID or COUNTRY. Concepts that came from one source form a model; models live in knowledge areas, the scope and security boundary. See the full hierarchy →
Six records, one value. The relationship exists the moment the data arrives.
Testing whether two records are related becomes an identity check, not a text comparison. When the Mapper merges models it bridges concepts that share a name and keeps every unmatched record — so "customers who never ordered" and "products never sold" arrive as findings, not as losses.
No foreign keys to declare, no join keys to guess. Shared values are the joins.
Fix a value once and every record that points at it is correct — in every system.
Unmatched rows are kept and handed back as a free data-quality audit.
The AtomicDB grid lives in memory. Every value already has its place, so there is no index to design, build, tune or rebuild — a lookup goes straight to the value. Disk is for backup, the ledger and large files only.
On the measured workstation, no read touches the disk while a query runs. One process on commodity hardware stands in for a warehouse cluster, a vector database and a GPU inference node.
Writes land in a write area; reads are served from a separate read area, with a single replication step between them. Analytical reads and live ingest do not contend, and a reader never sees a half-written change.
An update writes a new version and keeps the old one as history. Every change is recorded on a write-once ledger whose heads are signed by a separate key custodian; inclusion and consistency can be checked to a published standard (RFC 9162), and a keyed chain detects a rewritten segment, not only a damaged one.
"Was this contract compliant on that day?" is answered from the record as it stood then.
A date before the record began says so — it never invents history.
Supplier recorded: ACME LTD
Corrected to ACME LIMITED — consented, with who and why.
Contract award passes the gate; evidence sealed on the ledger.
Returns v1 — exactly what the system knew that day.
Spelling variants, stray spaces and duplicate rows fold into one identity. The original text is kept word for word beside it.
A correction is previewed with every system and record it would touch, then applied everywhere at once — and recorded so it can be reversed.
If any part fails, nothing is merged and the system says exactly what failed.
ATLAS proposes likely duplicates and missing links, labelled as predictions until a person promotes them.
A value that breaks a rule is set aside for a person — never silently cut to fit.
Checkpoints report "verified" only when they pass verification; deploys compare served data before declaring success.
Retrieval is a walk along real associations, not a similarity search — so no GPU is needed. The local language model runs on the processor and only puts into words what the AtomicDB grid has already found. A claim with no supporting record is reported as "no evidence".
Turns words into a walk of the grid and returns an evidence table with every answer.
Reasons over the whole dataset as a map of relationships: paths, clusters, the same thing under two names.
Holds law and obligations as data and returns a verdict with the provision it applied.