Comparison
GraphANN™ vs your shortlist.
Pick a competitor below for a head-to-head capability comparison. We've kept it honest. Every cell links to the vendor's own docs where the claim can be verified.
Compare against
OSS + Qdrant Cloud
| Capability | GraphANN™Commercial · self-host | QdrantOSS + Qdrant Cloud |
|---|---|---|
| Storage / chunkPer-chunk index footprint: full-vector stores keep the raw embedding; GraphANN keeps codes + graph. Before vendor compression | ~1 KB (index footprint only) | ~10 KB * |
| Recall accuracy — measuredJuly 2026 head-to-head: identical 250K-vector corpus (bge-small, 384-dim), identical embeddings, exact-KNN ground truth, native, warm. recall@10 (exact overlap); tie-tolerant recall is 1.000 for both GraphANN and Qdrant, 0.95 for Neo4j | 0.994 | 0.999 |
| Index storage — measuredSame benchmark; total on-disk index for the full 250K corpus (du). GraphANN on the efficient profile — 4.7× smaller than Qdrant, 13.7× smaller than Neo4j | 189 MB | 884 MB |
| Memory footprint — measuredSame benchmark; resident working set while serving. GraphANN's figure includes its embedding-runtime baseline the others don't carry, and is still ~3× smaller | 470 MB | 1,521 MB |
| Query latency — median, measuredSame benchmark; warm steady-state median, all engines warmed equally. GraphANN's index memory-maps lazily, so the first queries after an index load are slower (cold-start ~10 ms) before settling to the figure shown | 0.18 ms (warm) | 1.9 ms |
| Source-text storageOriginal chunk text persisted alongside the index | Built-in zstd | Payload field ↗ |
| Embedded embedding modelEmbedding runtime ships with the binary; no extra service needed | Bundled ONNX | FastEmbed lib ↗ |
| Hot-swap embedding modelSwitch model without rebuilding the index | Background job | Full reindex |
| Migration without re-uploadExisting chunk records survive, no re-upload from your app required | Native | Re-upsert |
| Self-host / air-gapRun inside your VPC, no outbound calls | Single binary | OSS self-host |
| Managed cloud todayFully-hosted offering available now | Roadmap | Qdrant Cloud ↗ |
| Multi-tenant isolationPer-tenant indexes, RBAC, quotas built in | Per-tenant + RBAC | Payload-keyed ↗ |
| Hybrid text + vectorCombine BM25-style and vector retrieval | Built-in | Sparse + dense ↗ |
| Generic metadata pre-filterPredicate pushed into graph-based nearest-neighbour search | Equality on typed fields | Payload filter ↗ |
| LicenceHow procurement reviews the source / contract | Commercial (closed) | Apache 2.0 ↗ |
* Qdrant with compression-enabled indexes uses vendor-side compression that reduces the per-chunk footprint below the uncompressed baseline. The 10 KB figure is the uncompressed embedding + index-overhead baseline; actual numbers vary with the index configuration you choose.
How the measured rows were produced
Testing methodology, end to end
The measured rows above come from one benchmark run. Here is exactly how it was set up, so you can reproduce it or challenge it. Every engine sees the same data, the same queries, and the same scoring.
- 1Same corpus for every engine250,000 real 384-dimensional embeddings are loaded, unchanged, into each engine. No engine gets a different, smaller, or pre-filtered dataset.
- 2Queries drawn from the data300 query vectors are sampled evenly across the corpus, and each is excluded from its own results — so a correct answer is never trivially the query itself.
- 3Exact ground truthThe true nearest neighbours are computed by brute-force cosine over the full corpus — no approximation. Every engine is then scored against the same correct answers.
- 4Recall, measured two waysrecall@10 is the share of each query's 10 true neighbours the engine actually returns. A tie-tolerant variant also credits any returned vector within 1e-3 cosine of the 10th true neighbour, because this corpus contains near-duplicate vectors that create artificial ties.
- 5Storage is bytes on diskIndex storage is the actual on-disk size of each engine's data directory after a full build — measured, not reported or estimated.
- 6Latency measured warmEvery engine is warmed with one full query pass, then the median single-query round-trip is recorded, so all engines are compared at steady state on identical hardware.
- 7One engine at a timeNative builds, no emulation, run one after another on the same machine, so nothing competes for CPU or memory while an engine is being measured.
- 8Competitors in production configQdrant and Neo4j run in their recommended production configurations; the cells link to each vendor's own docs. Pinecone, Weaviate, pgvector and Milvus are capability-only in this table, not part of this measured run.
- 9What we discloseGraphANN is measured on its efficient profile. Its index memory-maps lazily — fastest once warm, slower on the first queries after a load (the cold-start noted above). These figures are for the client-supplied-vector path; text-ingested workloads store less again.
Where Qdrant leads
Honest about the gaps
- Managed cloud. Qdrant Cloud is the official hosted offering. GraphANN™ ships as a self-host binary today; a managed tier is on the roadmap.
- Operators and arbitrary keys on filters. Qdrant's payload filter supports any user-defined key with a full operator set (must / should / must_not, gt / lt / in, geo, etc.). GraphANN™ supports equality (AND-combined) over typed ChunkMetadata fields, broader operators and arbitrary user-defined keys are roadmap.
- Aggressive compression. Qdrant offers several vector-compression modes for 4-32× storage reduction at some recall cost. GraphANN takes a different path: a multi-level approach that stays approximate at scale and exact for the final candidates, so no full-precision vectors are ever persisted.
Your evaluation
Want this matrix sized to your specific workload?
Send us your shortlist and your scale, and we'll come back with a head-to-head comparison that uses your actual numbers, including wins for the other side where they apply.