Benchmarks

The numbers, and exactly how they were measured.

Measured on engine 0.9.15, on 2026-08-21, against a graph pinned to exactly 3,000,000 edges. Every chart below is drawn from that run's own output — these are CognoDB's own results, and this page publishes no numbers about anyone else's database.

48,662/s
Read queries1
0.56 ms
2-hop p952
100,298/s
Ingest edges3
106 B
On-disk / edge4
  1. 1Read-only throughput: 40 concurrent clients replaying a seeded workload for 60 s. The mixed run (10% writes) sustained 37,751/s, and the write-only run 23,932/s. Measured 2026-08-21 on engine 0.9.15 (commit 3106d98). SNAP soc-Pokec loaded to exactly 3,000,000 edges over 663,230 nodes, on one n2-standard-8 (8 vCPU / 32 GiB, Intel Cascade Lake), engine on defaults, median of 3 reps after a discarded warm-up.
  2. 2p95 latency for a two-hop, friends-of-friends traversal against the loaded graph (p50 0.20 ms). Measured 2026-08-21 on engine 0.9.15 (commit 3106d98). SNAP soc-Pokec loaded to exactly 3,000,000 edges over 663,230 nodes, on one n2-standard-8 (8 vCPU / 32 GiB, Intel Cascade Lake), engine on defaults, median of 3 reps after a discarded warm-up.
  3. 3Edges merged per second, sustained while loading the graph over Bolt in batches, alongside 198,929 nodes/s. Measured 2026-08-21 on engine 0.9.15 (commit 3106d98). SNAP soc-Pokec loaded to exactly 3,000,000 edges over 663,230 nodes, on one n2-standard-8 (8 vCPU / 32 GiB, Intel Cascade Lake), engine on defaults, median of 3 reps after a discarded warm-up.
  4. 4On-disk store size divided by edges loaded (304 MB for 3,000,000 edges), read from the container's cgroup counters rather than self-reported. A compact store keeps the working set cached. Measured 2026-08-21 on engine 0.9.15 (commit 3106d98). SNAP soc-Pokec loaded to exactly 3,000,000 edges over 663,230 nodes, on one n2-standard-8 (8 vCPU / 32 GiB, Intel Cascade Lake), engine on defaults, median of 3 reps after a discarded warm-up.

Latency

Per-query latency, not just an average.

A median hides the tail that users actually notice, so every query shape is reported at p50, p95 and p99 across the measured reps.

Point lookup · read mixlower is better · ms
p50
0.45 ms
p95
2.50 ms
p99
5.04 ms
MATCH (n:SocialUser {id:$x}) RETURN n.id
1-hop expand · read mixlower is better · ms
p50
0.46 ms
p95
2.56 ms
p99
5.20 ms
MATCH (:SocialUser {id:$x})-[:FRIEND]->(m) RETURN count(m)
2-hop expand · read mixlower is better · ms
p50
0.50 ms
p95
3.45 ms
p99
7.95 ms
MATCH (:SocialUser {id:$x})-[:FRIEND]->()-[:FRIEND]->(m) RETURN count(m)
Property write · write mixlower is better · ms
p50
2.20 ms
p95
3.43 ms
p99
5.69 ms
MATCH (n:SocialUser {id:$x}) SET n.v = $v
Edge merge · write mixlower is better · ms
p50
0.32 ms
p95
0.81 ms
p99
1.48 ms
MATCH (a {id:$x}) MATCH (b {id:$y}) MERGE (a)-[:FRIEND]->(b)

Throughput

What it sustains, and while writing.

Read-only is the easy number. The mixed and write-only mixes are the ones that show what contention costs.

Queries per second · 40 concurrent clientshigher is better · queries/s
Read-only
48,662
Mixed (10% writes)
37,751
Write-only
23,932

20 errors across the measured reps.

Sustained edge ingest, across the load windowedges/s
Sustained edge ingest, across the load window — edges per second against window038k75k113k150k123456window
Values
windowedges/s
1111,514
2105,403
3105,974
498,059
5102,899
6100,064

Ingest rate per window while loading the graph over Bolt. A flat line is the point: the rate holds as the store grows rather than decaying, because folding runs alongside the load instead of stopping it.

Methodology

One public dataset, one stock machine, no tuning.

Every figure above comes from the same run: the public SNAP soc-Pokec social graph loaded into CognoDB 0.9.15 on a single Google Cloud n2-standard-8 (8 vCPU / 32 GiB, Intel Cascade Lake), with the load generator on a second machine one hop away so the client never competes with the database for CPU. The engine ran on its defaults — no configuration flags, no cache warming beyond a single discarded warm-up rep — and every reported number is the median of 3 measured repetitions.

The graph is pinned to exactly 3,000,000 edges over 663,230 nodes. That detail matters more than it sounds: the serve legs run against whatever the load left behind, so a build that ingests faster would otherwise be measured against a larger graph and score worse for it. Pinning the edge count is what makes one run comparable to another.

Queries were driven over Bolt with standard drivers — the same protocol and code path a production application uses. Storage figures are read from the container's cgroup counters rather than self-reported by the engine.

Engine build
0.9.15 (3106d98)
Measured
2026-08-21
Machine
n2-standard-8 · Intel Cascade Lake
Graph
3,000,000 edges / 663,230 nodes
Concurrency
40 clients, 60 s per leg
Reps
3, median reported

Workloads

What each number actually measures.

Read queries

48,662/s

Read-only throughput: 40 concurrent clients replaying a seeded workload for 60 s. The mixed run (10% writes) sustained 37,751/s, and the write-only run 23,932/s. Measured 2026-08-21 on engine 0.9.15 (commit 3106d98). SNAP soc-Pokec loaded to exactly 3,000,000 edges over 663,230 nodes, on one n2-standard-8 (8 vCPU / 32 GiB, Intel Cascade Lake), engine on defaults, median of 3 reps after a discarded warm-up.

2-hop p95

0.56 ms

p95 latency for a two-hop, friends-of-friends traversal against the loaded graph (p50 0.20 ms). Measured 2026-08-21 on engine 0.9.15 (commit 3106d98). SNAP soc-Pokec loaded to exactly 3,000,000 edges over 663,230 nodes, on one n2-standard-8 (8 vCPU / 32 GiB, Intel Cascade Lake), engine on defaults, median of 3 reps after a discarded warm-up.

Ingest edges

100,298/s

Edges merged per second, sustained while loading the graph over Bolt in batches, alongside 198,929 nodes/s. Measured 2026-08-21 on engine 0.9.15 (commit 3106d98). SNAP soc-Pokec loaded to exactly 3,000,000 edges over 663,230 nodes, on one n2-standard-8 (8 vCPU / 32 GiB, Intel Cascade Lake), engine on defaults, median of 3 reps after a discarded warm-up.

On-disk / edge

106 B

On-disk store size divided by edges loaded (304 MB for 3,000,000 edges), read from the container's cgroup counters rather than self-reported. A compact store keeps the working set cached. Measured 2026-08-21 on engine 0.9.15 (commit 3106d98). SNAP soc-Pokec loaded to exactly 3,000,000 edges over 663,230 nodes, on one n2-standard-8 (8 vCPU / 32 GiB, Intel Cascade Lake), engine on defaults, median of 3 reps after a discarded warm-up.

Token economics

The benchmark that matters for AI workloads.

Token economics

Cut LLM token costs by ~98.7%.

Instead of dumping the whole knowledge base into context every turn, CognoDB retrieves only the connected neighbourhood relevant to the current query. At 3,700 entities, that drops from 202,285 tokens per query to 2,668, and the gap widens as the graph grows, because baseline tokens scale with corpus size while graph-retrieval tokens stay bounded by neighbourhood size.

Token counts measured with the GPT-4 BPE tokenizer (cl100k_base) over identical rendered text: the graph path fetches the 2-hop neighbourhood around the query entities, the baseline dumps every node and edge. Savings scale with knowledge-base size; retrieval stays bounded by neighbourhood, not corpus.

Whole knowledge base202,285 tokens
Connected neighbourhood2,668 tokens
Baseline tokens
202,285per query @ 3.7K entities
Graph retrieval
2,668per query @ 3.7K entities
Saved per query
~199,617tokens avoided
Cost saved / 1K queries
~$599at $3 / 1M input tokens
Token efficiency~98.7%
Tokens per query as the knowledge base growsDump everythingGraph retrieval
Tokens per query as the knowledge base grows — tokens per query against entities in the knowledge base063k125k188k250k1854629252k4kentities in the knowledge base
Values
entities in the knowledge baseDump everythingGraph retrieval
1859,4983,562
46223,7793,014
92547,8823,107
1,85095,5282,671
3,700202,2852,668

The saving is not one number — it is a widening gap. At 185 entities retrieval saves 62%; at 3,700 it saves 99%, because dumping the corpus scales with the corpus while retrieving a neighbourhood does not. On a small knowledge base the advantage is real but modest, and quoting only the largest row would overstate it.

What we don't publish

No competitor numbers.

Cross-vendor benchmarks are only honest when the harness, dataset, hardware and configuration are all published and reproducible, and when the vendor publishing them has no thumb on the scale. Rather than publish numbers about other databases measured by us, this page sticks to CognoDB's own results and their methodology. The rest of our claims posture is on the same page it's always been: see Why CognoDB.

Start now

~98.7%

token efficiency at 2,000 entities (see the footnotes above)

Run your own benchmark.

The most credible benchmark is yours: your queries, your data, your drivers. A free instance takes about a minute and no card.

Start free Read the claims posture

First-graph path

Live

  1. Create a free instance

    No card. Ready in about a minute.

  2. Connect your driver

    bolt+s:// URI into the driver you already use.

  3. Write two MERGEs

    That's the entire shape of agent memory.

  4. Point an agent at it

    One MCP config block. No integration code.