AtomicDB vs
the field.

Page 0 · The yardstick

What "the same thing" means

Five capabilities, held simultaneously. Each competitor page grades all five.

AtomicDB's evidence — measured on the running engine, 2026-09-01

The scale story — single node today, designed for the cluster, designed beyond it

Today: one node. Every measured number in this guide is single-node truth — that is what ships, and no page pretends otherwise.

Designed for: the 16-node reference cluster. Each page closes with "the 16-node question" — how the comparison shifts on the build the architecture was drawn for: 16 nodes × dual EPYC (Gen 5 "Turin" / Gen 6) × 9 TB RAM = 144 TB of Matrix-serviceable memory, ~6,100–8,200 cores, ~18 TB/s aggregate bandwidth, on the order of ~100 billion rows live in RAM. The AtomicDB Matrix needs no coordinator to shard because its addresses are arithmetic: the Matrix partitions deterministically into sixteen equal segments, a knowledge area's anchor is computed from its registered identity, and bridge lookups hash-route by value name — placement is computed from the data, not looked up from a directory that must scale with it.

Designed beyond: the association network of clusters. The same principle that associates records is designed to associate clusters. Instances already recognise one another in the shipped engine — the device group, attested gossip, and replication are live today — and because every address is computable from the data itself, a value's home cluster is as arithmetic as its home coordinate. Clusters federate the way records join: by shared-value routing across the association network, with no central coordinator to outgrow — and the addressing protocol of that network is IPv6, by design. The 128-bit address space is wide enough to embed the grid's own addressing: a prefix names the cluster, a segment names the node's Matrix partition, and the interface bits carry the datum's Matrix address — so a datum's home is not merely computable, it is a routable address, and the internet's own routing fabric carries association traffic instead of an overlay directory. At 2¹²⁸ addresses the ceiling is nearly unlimited clusters in design; in shipping fact, the single-image cluster engine is the stated roadmap item, and the 16-node build is its first staging post. Page 11, The AtomicDB Network states this design in full.

Two constants hold on every page: hardware moves the capacity axis, never the semantic one — and design claims are always labelled as design, measured claims as measured.

The market's own summary of the closest neighbor: "nothing replicates the associative engine exactly." The pages that follow show each technology holding one or two of the five — never all.

Page 1 · The interface

There is no query language

The question is a value. The answer is everything associated with it.

Every technology in this guide asks its users to learn a language before asking a question — SQL (a multi-part ISO standard), Cypher/GQL, SPARQL, DAX (250+ functions), the Elasticsearch Query DSL. AtomicDB has none. There is no grammar, no parser, no query planner to out-guess. A question is a value selection — an item id, obtained by listing or by clicking — and the engine returns the associated world. Below is the same real question from this engine's own test data, asked four ways: "show me everything related to sequencing run RUN-00002, across all six sources."

-- someone had to KNOW all seven keys,
-- and author the join graph by hand
SELECT * FROM genome_sequencing s
FULL OUTER JOIN genome_variants v
  ON  v.sample_id  = s.sample_id
  AND v.gene       = s.gene
FULL OUTER JOIN clinical_trials t
  ON  t.subject_id = s.subject_id
FULL OUTER JOIN clinical_outcomes o
  ON  o.subject_id = t.subject_id
  AND o.trial_id   = t.trial_id
FULL OUTER JOIN materials_assay a
  ON  a.lab_site   = s.lab_site
FULL OUTER JOIN materials_fatigue f
  ON  f.specimen_id = a.specimen_id
  AND f.material    = a.material
WHERE s.run_id = 'RUN-00002';
-- and it is still wrong: WHERE defeats
-- FULL OUTER, and a 7th source means
-- rewriting the query

-- step 0, the part the demo skips:
-- BUILD the edges, once per bridge,
-- re-run when data arrives
MATCH (s:Run),(a:Assay)
WHERE s.lab_site = a.lab_site
CREATE (s)-[:AT_SITE]->(a);
-- ... x7 bridges ...

-- then the traversal
MATCH p=(r:Run {run_id:'RUN-00002'})
        -[*1..4]-(x)
RETURN p;
-- agreement on OTHER shared fields is
-- a WHERE the author must remember

SELECT * WHERE {
  ?run  :run_id     "RUN-00002" ;
        :sample_id  ?smp ; :gene ?g ;
        :subject_id ?subj ;
        :lab_site   ?site .
  ?var  :sample_id  ?smp ; :gene ?g .
  ?tri  :subject_id ?subj ;
        :trial_id   ?tid .
  ?out  :subject_id ?subj ;
        :trial_id   ?tid .
  ?asy  :lab_site   ?site ;
        :specimen_id ?spec .
  ?fat  :specimen_id ?spec . }
-- outer semantics need OPTIONAL{}
-- around every block

POST /api/hierarchy/records_for_value
{ "item_ids": ["2825098"],   <- the value
  "expand_bridges": true,
  "model_ids": [ ...the six models... ] }

-> 86,544 rows, all 34 columns,
   total exact, truncation reported

-- in the Mapper: Ctrl+click RUN-00002.
-- that is the entire query.
-- a 7th source? ingest it — same call,
-- nothing rewritten.

The whole surface an application uses

Roughly ten calls of plain JSON carry everything an application does daily. The full engine surface — including PKI, backup, replication, diagnostics, and administration — is 148 REST routes, enumerated in one reference document; compare that to the page count of the SQL standard or the function count of DAX for the read path alone.

The four samples answer the identical question over this guide's own six-model test set; the AtomicDB call and its results (86,544 rows, exact vs independently computed ground truth) are the measured run from 2026-09-01. Route count per docs/API_HTTP_ENDPOINTS.md (148 routes, verified against the dispatcher).

Page 2 · In-memory associative BI — the real neighbor

Qlik Sense / QlikView — the QIX Associative Engine

In production ~30 years · enterprise install base in the tens of thousands · the engine behind green/white/grey

Where it genuinely does the same thing

QIX is the one production engine built on the same idea. Loaded tables associate automatically on identical field names; every selection recolours the entire model instantly — green selected, white still possible, grey excluded — across millions of rows in memory. It validated the associative model commercially, and its auto-association-by-name is the same design choice AtomicDB's bridge concepts make.

Where it stops short

The 16-node question

A QIX app is bound to one node's RAM, and large Qlik apps strain in the tens-of-gigabytes; Sense scales by distributing apps across nodes, never one associative model across the cluster. The reference build runs a single associative model over 144 TB — two to three orders beyond any production QIX app — while remaining the database of record underneath it. What the cluster does not change: Qlik's thirty-year visualization surface and ecosystem. Hardware moves capacity, not product maturity, and the page's concession stands on that axis alone.

Sources: Qlik associative selection model · Qlik's Associative Model white paper · Synthetic keys guidance · "nothing replicates the associative engine exactly"

Page 3 · Cloud data warehouse

Snowflake

The dominant cloud warehouse · columnar micro-partitions · storage / compute / services separated

What it actually is

Snowflake stores tables as immutable compressed columnar micro-partitions on object storage and scales compute independently. It is superb at what it claims: elastic SQL analytics over governed, shared data. Every join is declared — written in SQL against keys the modeler chose, tuned by clustering keys on the columns that appear in JOIN conditions. Nothing associates by itself; a value shared between two tables means nothing until a human writes the join.

Where it stops short

The 16-node question — the reference cluster scenario

On the reference build — 16 nodes, dual EPYC (Gen 5/6), 9 TB per node — the concession above narrows. Most enterprise Snowflake accounts keep their active tier well under 100 TB; 144 TB of RAM holds that whole tier in memory, where Snowflake's path crosses a network to object storage with SSD cache in between. The associative click-pivot pattern — thousands of small, chained lookups — is a warehouse's worst case and the AtomicDB Matrix's native one. The economics follow: a large warehouse held hot for interactive work bills in the millions per year, and the cluster's capex is comparable within one to two years at sustained load (rough figures, stated as such), with on-prem sovereignty as a side effect. What hardware does not change cuts both ways: Snowflake's joins stay declared SQL at any scale — the RelationalAI coprocessor itself runs as billed Snowpark compute — and on our side the distributed single-image grid remains the stated roadmap item. Snowflake's residue: cross-organization data sharing and its marketplace (a network effect no hardware buys), zero-ops elasticity with scale-to-zero, the multi-petabyte cold tail, and the SQL/BI governance ecosystem.

Sources: Snowflake architecture 2026 · Micro-partitions deep dive · RelationalAI native-app white paper

Page 4 · Wide-column NoSQL

Google Bigtable

Fully managed wide-column store · the design paper behind HBase & Cassandra · petabyte key-value scale

What it actually is

Bigtable is a key-ordered, wide-column store optimized for fast single-row access and horizontal scale. Its own schema guidance is the opposite philosophy of association: denormalize so that each query hits a single table, and design the row key around the one access path you will need. Even with GoogleSQL support added, the documentation is explicit: no JOINs between tables, no subqueries, no UNIONs; transactions live within a single row.

Where it stops short

The 16-node question — the reference cluster scenario

On the reference build — 16 nodes, dual EPYC (Gen 5 "Turin" 9005-class, or Gen 6), 9 TB RAM per node — the picture above changes on the capacity axis: 144 TB of RAM, ~6,100–8,200 cores, ~18 TB/s aggregate memory bandwidth, on the order of ~100 billion rows live in memory. That is Bigtable's own scale territory — served from RAM instead of SSD, and still associative, where Bigtable's no-JOIN design holds at any node count. The AtomicDB Matrix shards naturally: it partitions deterministically into sixteen equal segments, every knowledge area's anchor is computed arithmetically from its identity, and bridge lookups hash-route by value name. Stated honestly: the distributed engine is a roadmap item — replication, gossip and attestation ship today; the single-image cluster grid does not. With it, Bigtable's remaining exclusives reduce to managed elasticity, global replication SLAs, and the multi-petabyte tail beyond ~150 TB live.

Sources: GoogleSQL for Bigtable — overview & limits · Bigtable schema design guidance · GoogleSQL on Bigtable in practice (2026)

Page 5 · Native graph database

Neo4j — and the property-graph family

Index-free adjacency · Cypher variable-length paths · TigerGraph, Neptune, ArangoDB in the same family

Where it genuinely does the same thing

Transitive reach is Neo4j's home turf. Variable-length path expressions ([:REL*1..5]) walk persisted relationships in milliseconds where relational join-chains take seconds — traversal without computing joins is precisely the "pointer math" an associative read should be, and Neo4j does it in production at serious scale.

Where it stops short

The 16-node question

Neo4j scales reads by replication and shards by database (composite/Fabric), where cross-partition traversal is the operator's problem — one graph across many nodes is its hard case too, so the roadmap caveat cuts evenly here. At 144 TB the capacity race is a draw of ambitions; what the iron cannot buy Neo4j is the semantic half: edges still have to be built before they can be traversed, and the memoized pointer-math walk already matches the index-free-adjacency behavior its performance case rests on. The residue is unchanged: the algorithms library and a decade of curated-graph practice.

Sources: Neo4j — the power of the path · Traversal vs relational joins · Variable-length traversal

Page 6 · Semantic triple stores

RDF / SPARQL stores — Stardog, GraphDB, Virtuoso

W3C standards stack · joins by term unification · property paths for transitivity

Where it genuinely does the same thing

The closest semantic cousin. In SPARQL, triple patterns join by unification — two patterns sharing a term join on its value, no declared key anywhere. Property paths give transitive reach. Conceptually, this is value-based association with transitivity, standardized.

Where it stops short

The 16-node question

At 144 TB a triple store holds tens of billions of triples in memory — and stays join-bound: every SPARQL hop is still index scans and joins, which is the 1–2 order-of-magnitude gap the literature already measures on deep paths. The memoized walk turns repeated subtrees into arithmetic instead; more RAM widens that difference rather than closing it. The standards residue — federation, OWL/SHACL reasoning, public knowledge graphs — is untouched by hardware, which is exactly why it remains the honest concession.

Sources: RDF 1.2 vs Neo4j/OpenCypher · SPARQL with paths

Page 7 · Real-time entity resolution

Senzing — and Tilores, Tamr

v4 in 2026 · resolves on ingest, queryable immediately · deployments from <1M to ~100B records

Where it genuinely does the same thing

Senzing links records by shared attribute values in real time, as they arrive — names, addresses, identifiers — with feature traceability from raw attribute to resolved link. That is genuine implicit value-association in production, at up to ~100 billion records, and it deserves the credit.

Where it stops short

The 16-node question

Senzing already operates at ~100 billion records, so the reference build creates parity of scale rather than an advantage — 144 TB puts the AtomicDB Matrix in the same population class. What hardware cannot change is the scope of the question: at any size, Senzing resolves identity and stops; the Matrix reconstructs everything the resolved record participates in. The two remain complementary — an identity resolver in front of an associative engine is a pipeline, not a rivalry — and Senzing keeps the probabilistic-matching residue outright.

Sources: Senzing v4 release · What is entity resolution

Page 8 · Declared-model BI engines

Power BI (VertiPaq) — and Tableau Hyper, Sisense, Spotfire

The BI volume leaders · in-memory columnar · relationships authored in the model

What it actually is

VertiPaq and Hyper are excellent in-memory columnar engines — but their filter propagation follows relationships a modeler declared, with cardinality and cross-filter direction chosen by hand. Cross-filtering feels associative inside one well-built model; it is the model's author, not the data, doing the associating. The 2026 comparisons are blunt: the alternatives cover dashboards, and none reproduce Qlik's associative selection model — much less its transitive extension.

Where it stops short

The 16-node question

The comparison becomes bluntest here: Power BI's largest premium capacities cap a semantic model in the hundreds of gigabytes; the reference build serves 144 TB — roughly two and a half orders beyond the biggest model Microsoft will host — and does it without a modeler declaring a single relationship. Hardware does not move their semantic position at all: declared relationships stay declared at any capacity tier. The distribution residue (Microsoft 365 reach, per-seat pricing) is a go-to-market fact no cluster changes, and the page keeps conceding it.

Sources: Qlik competitors 2026 · Alternatives review — "none reproduce the associative selection model"

Page 9 · Search & log analytics

Elasticsearch / OpenSearch — and Splunk

Inverted indexes over values · faceted aggregations · the observability default

Where it resembles the same thing

An inverted index is value-first by nature, and Kibana's faceted drill-down — click a value, watch every panel narrow — is the closest mainstream experience to the associative pivot. Splunk's search-time field extraction lives in the same family.

Where it stops short

The 16-node question

Search clusters scale horizontally to petabytes, so the reference build does not out-scale them — this is the one page where the iron levels rather than tilts. What it levels is revealing: at equal hardware, the structural position is unchanged, because denormalization is not a size problem. A petabyte of flattened documents still cannot answer a relation that was never flattened in, and 144 TB of the AtomicDB Matrix serves the joined truth with nothing pre-flattened. Full-text relevance and log economics remain theirs; the residue is genuine and hardware-independent.

Sources: field-standard behavior per vendor documentation; comparative framing per 2026 analytics landscape reviews.

Page 10 · Ontology platforms

Palantir Foundry

Ontology-driven analysis at government & enterprise scale · analysts pivot across linked objects

Where it resembles the same thing

The analyst experience — walk from an object to everything linked to it, pivot, keep walking — is the closest workflow match in production, and it operates at national scale. The pivot surface is real and battle-tested.

Where it stops short

The 16-node question

Foundry already runs on clusters; iron was never its differentiator, and it is not the axis this page contests. What the reference build changes is the excuse structure: at 144 TB in RAM there is no scale reason left to accept the ontology-authoring engagement, and the cost contrast sharpens — a capex cluster against platform contracts that commonly run eight figures a year, with the linking done by the data instead of by forward-deployed engineers. The workflow and services residue stands: institutional integration is a product Foundry ships and a single engine does not.

Sources: vendor documentation and public deployment reporting; capability framing consistent with the ontology-authoring model described in Palantir's own platform materials.

Page 11 · The road ahead — a design page

The AtomicDB Network

Records associate into knowledge. Clusters associate into a network. Same principle, one level up.

Everything on this page is design, not shipped product — stated here because it is the same idea the measured pages already proved at record scale, applied at cluster scale. Inside one engine, a value placed in the AtomicDB Matrix finds its related records by association, with no join author and no central catalog. The Network design extends exactly that: clusters find their related clusters by association — by the values and knowledge areas they choose to share — with no central coordinator to outgrow.

A worked example — Medical · Insurance · Government

Picture three independent clusters, each sovereign over its own data: a hospital group's Medical knowledge cluster, an Insurance cluster, and a Government registry cluster. Each publishes some of its knowledge areas into the network — in whole or in part: a whole KA, selected models, or an ACL-scoped slice. What the published slices form together is a Virtual Knowledge Area — queryable exactly like a local KA, materialized nowhere, owned by no one member.

A clinician pivots on a patient identifier. The Medical cluster contributes diagnosis and treatment records; the Insurance cluster's published slice joins on the shared policy identifier and contributes coverage and claim rows; the Government registry joins on the registry identifier and contributes licensure and vital-record rows. The result is the same transitive full-outer recordset Page 1 demonstrated on one node — assembled across administrative boundaries, while every cluster keeps custody of its own data. What was never published never leaves home: the virtual KA is defined by the publication contracts, not by copying databases into a lake.

How the pieces are designed to work

Design page — no measured claims. Shipped-substrate items (PKI, device group, attestation, gossip, replication, ACL scoping) refer to the current single-node engine; everything cross-cluster is design intent as of 2026-09-01.