Qdrant FineWeb 10B Benchmark Confronts AI Search’s Small-Data Problem
Qdrant released a 10-billion-document search dataset, confronting a basic conflict in AI infrastructure: production systems are huge, while many accepted tests remain comparatively small. The Qdrant FineWeb 10B benchmark gives researchers a public corpus with dense and sparse vectors, filtered queries, and exact nearest-neighbor results. Its scale makes familiar shortcuts harder to hide.
The release does not declare Qdrant the fastest vector database. It creates shared infrastructure for testing Qdrant, Milvus, Elasticsearch, and other retrieval systems under demanding conditions. That distinction matters because vendor performance charts often reflect different datasets, hardware, recall targets, filters, and client settings.
The central contest is therefore not Qdrant against one named rival. It is open, reproducible measurement against convenient benchmark claims. Qdrant has made that contest more serious, but it has not settled every question about production search quality.
The Qdrant FineWeb 10B Benchmark Changes the Starting Point
Qdrant has moved the public benchmark conversation from millions of vectors to more than 10 billion real web documents.
Released on September 1, 2026, Qdrant-FineWeb-10B draws from FineWeb, a curated corpus derived from Common Crawl. The public dataset card lists 10,074,324,060 records.
Each record includes the original document payload and metadata. It also contains one dense embedding and one sparse embedding produced with Alibaba’s gte-multilingual-base model. A dense embedding represents a document as a fixed-length numerical vector, while a sparse embedding records weighted terms across a much larger vocabulary.
The dense representation has 768 dimensions. Its vectors are normalized for cosine similarity, a measure of directional closeness between vectors. The sparse representation uses weighted token identifiers and dot-product scoring.
That common corpus supports comparisons across dense, sparse, filtered, and hybrid retrieval. Hybrid retrieval combines semantic matching with term-based signals, helping systems handle both broad meaning and exact names or phrases.
The release also supplies 119,953 queries across four groups. These include 100,000 dense queries, 10,000 sparse queries, 4,953 text-filtered dense queries, and 5,000 structured-filtered dense queries. The queries come from Microsoft’s MS MARCO datasets.
For each query, Qdrant provides the exact top 1,000 nearest results. Exact results form the ground truth, meaning the reference answer used to measure whether a faster approximate index missed relevant neighbors.
Producing that reference set required exhaustive search across the corpus. Qdrant says the work involved more than one quadrillion distance calculations on GPU-based infrastructure. That is important because approximate nearest-neighbor systems deliberately avoid comparing every query against every stored vector.
Approximation makes search practical, but it introduces misses. Without exact ground truth, developers cannot calculate recall reliably. Recall measures how many of the true nearest results an approximate system retrieves.
The Qdrant FineWeb 10B benchmark therefore changes the available test material, not merely its size. Teams can examine ingestion speed, index construction, memory use, latency, throughput, filters, and recall against the same public reference set.
Qdrant also published two related datasets. PubMed-Multi-Vector holds dense, sparse, and ColBERT-style representations over one medical corpus. Coyo-Vector-Embeddings targets multimodal retrieval using text and image-caption pairs.
Those additions acknowledge that modern search is no longer limited to one vector per document. Some systems combine multiple representations, metadata conditions, reranking, and images within the same request.
Before this release, Qdrant’s own public comparison page used datasets ranging from about one million to 10 million vectors. The company now argues that those scales cannot reveal every problem faced by distributed production systems.
That argument has historical support. The Billion-Scale ANN study noted that much earlier empirical work concentrated on datasets containing roughly one million points. Its authors created a broader evaluation framework because search, recommendation, and ranking systems were already operating at billion-scale.
Qdrant is extending that direction with web-derived data, deeper result sets, several retrieval modes, and reusable infrastructure. The change raises expectations for anyone making large-scale AI search claims.
Why Small Benchmarks Can Produce Big Misunderstandings
A benchmark can report precise numbers while answering the wrong production question.
Vector search benchmarking is unusually sensitive to test design. Query rate means little without the achieved recall. Latency cannot be interpreted without knowing the result depth, filter selectivity, concurrency, index configuration, and available memory.
A system returning 90 percent recall may process more queries than one returning 99 percent. That does not automatically make it better. The missing results might contain the evidence needed to answer a difficult customer question.
The difference becomes more important when applications retrieve hundreds or thousands of candidates for a reranker. A reranker is a second-stage model that reorders a broader candidate set using more detailed relevance signals. It cannot recover a document that the initial retrieval stage never returned.
Small datasets can also fit comfortably within memory on one machine. At 10 billion records, teams must confront partitioning, routing, replication, disk access, network traffic, and uneven query workloads. These are system problems, not isolated algorithm problems.
Index construction presents another pressure point. An index that looks attractive after loading one million vectors may require impractical build time or temporary storage at a much larger scale. Updates and recovery can further change its operational value.
Filtering introduces similar complications. Many enterprise searches combine semantic similarity with conditions such as tenant identity, date, language, access rights, or product category. A fast unfiltered result does not show how the engine behaves when a filter eliminates most candidates.
Qdrant-FineWeb-10B includes both text-based and structured filters. Its structured queries can apply numeric, date, and set conditions. That lets researchers test whether an index maintains accuracy and latency as eligible subsets become narrower.
The dataset also preserves web metadata. Real web text contains repeated passages, unusual distributions, long-tail topics, and near-duplicates. Randomly generated vectors rarely reproduce those characteristics.
That realism matters for retrieval-augmented generation, or RAG. A RAG system retrieves documents before a language model constructs an answer. Failures can come from weak retrieval, poor chunking, incorrect permissions, stale content, or generation errors.
A database benchmark isolates only part of that chain. Still, it can reveal whether the retrieval layer supplies the right candidates under controlled conditions. Teams building a searchable knowledge base need both infrastructure measurements and evaluations grounded in their actual documents.
Qdrant’s release pressures vector database vendors to publish more context with performance claims. Buyers should expect matched recall, clearly defined hardware, complete configurations, tail latency, indexing time, and resource consumption.
Tail latency measures slower requests near the end of the latency distribution. The 99th percentile, commonly called p99, indicates the threshold below which 99 percent of requests complete. It often matters more than an average when users expect consistent responses.
The benchmark also challenges internal engineering teams. Many organizations evaluate databases using a small sample because generating embeddings and exact answers at full scale is expensive. Those tests can miss nonlinear changes caused by sharding or memory pressure.
Public large-scale data lowers part of that barrier. It does not make a 10-billion-vector experiment inexpensive, but it removes the need to create the entire corpus and reference set independently.
Vultr says it supplied the compute and object storage used for embedding generation. According to its infrastructure account, Qdrant processed about 500,000 files and produced roughly 25 terabytes of embedding data in approximately five days.
Those figures describe dataset creation, not the cost or speed of running every database against it. That distinction prevents the release from becoming another unsupported performance claim.
Supernova Turns the Dataset Into a Reproducibility Test
The more consequential release may be Supernova, because a static dataset cannot standardize how databases are loaded, queried, and measured.
Qdrant released Supernova as an open-source framework covering four stages of vector search benchmarking. It generates embeddings, calculates exact ground truth, loads target databases, and runs search workloads.
The framework separates these jobs into specialized modules. nova-embed handles embedding generation across different models and storage systems. It partitions work among independent workers without relying on a central coordination database.
nova-bf performs brute-force ground-truth calculation. Brute force compares queries with every eligible vector, producing an exact reference set instead of an approximation. Qdrant says the module streams partitions from remote storage to avoid placing the full corpus in GPU memory.
The tool can process dense, sparse, and multi-vector representations. It can also evaluate filters on CPUs before transferring qualifying data to GPUs. That design attempts to reduce unnecessary movement when filters remove large portions of the corpus.
nova-load drives parallel ingestion into a database. This phase measures how quickly a system can accept the dataset and exposes operational constraints that pure query benchmarks ignore.
nova-storm generates concurrent search traffic. According to Qdrant’s release details, it records query throughput, several latency percentiles, build times, and recall against the exact results.
A separate controller, nova-dist, uses SkyPilot for cluster provisioning and job scheduling. Qdrant says the same YAML-based configurations can target major cloud platforms, Kubernetes, and Slurm-based high-performance computing clusters.
This design serves the release’s primary opponent: opaque benchmark claims. A published chart offers limited value if outsiders cannot inspect the workload or rerun the experiment. Public data and configuration-driven tools expose more assumptions.
The approach also permits competing vendors to challenge Qdrant’s choices. Milvus or Elasticsearch engineers can propose better configurations for their systems. Researchers can change hardware, concurrency, query mixes, and recall targets without rebuilding the ground truth.
That openness does not eliminate tuning bias. Qdrant naturally knows its own database better than its competitors. Its existing benchmark documentation explicitly acknowledges that the company can configure Qdrant more effectively and might overlook important optimizations elsewhere.
Reproducibility provides a response to that conflict, rather than proof of neutrality. When code, data, and settings are visible, other maintainers can identify weak configurations and submit changes.
Independent evaluation remains necessary. A September analysis from TechTarget cited several outside data specialists who viewed the dataset as a credible contribution. Analyst William McKnight said its combination of realistic web-text distributions and exact results appeared well suited to dense, sparse, and filtered tests.
Another analyst, Kevin Petrie of BARC, warned that organizations still need benchmarks based on their own workloads. That qualification defines the release’s actual value. A shared benchmark supports comparison, while a workload-specific test supports a purchase decision.
Supernova can help bridge those uses because teams can apply the framework to another corpus. They can retain the measurement pipeline while substituting private documents, queries, filters, and embedding models.
The Qdrant vector benchmark is therefore best understood as test infrastructure. It creates a public starting point and a repeatable process. It does not assign a universal winner.
What the 10-Billion Scale Still Does Not Prove
Scale corrects one weakness in vector search benchmarking, but it cannot represent every source of failure in an AI search product.
First, FineWeb is broad web text. An enterprise corpus may contain code, contracts, medical records, support tickets, product catalogs, meeting transcripts, or short internal messages. Those documents have different lengths, vocabularies, duplication patterns, and access rules.
Second, the benchmark uses one embedding model for its central dataset. Embedding models map text into vectors, and their behavior shapes the neighborhood being searched. Changing the model can change vector dimensions, sparsity, clustering, and retrieval difficulty.
The Qdrant FineWeb 10B benchmark uses gte-multilingual-base for both dense and sparse representations. That provides consistency, but performance under this model does not guarantee the same ranking under another model.
Third, exact nearest neighbors are not automatically the most useful documents. Ground truth answers whether an approximate system reproduced the embedding model’s closest matches. It does not determine whether those matches satisfy a user’s information need.
This distinction separates ANN recall from retrieval relevance. ANN recall asks whether the index found the vectors that exact computation would find. Relevance asks whether those documents actually help answer the query.
A system can achieve near-perfect ANN recall while using an embedding model that misunderstands a specialized domain. It can also return technically similar documents that are outdated, unauthorized, or redundant.
Qdrant’s own relevance guidance recommends a labeled set pairing queries with expected documents. That evaluation layer remains essential for teams deploying RAG or semantic search.
Fourth, the dataset card identifies a numerical reproducibility issue. The published ground truth used bfloat16 GPU arithmetic, while regeneration scripts produce float32 embeddings. Small numerical differences can reorder tied results or affect items near the top-1,000 boundary.
Qdrant disclosed the discrepancy and said it was working on a fix. The issue does not erase the dataset’s value, but it shows why public artifacts need independent inspection.
Fifth, access creates a practical barrier. The Hugging Face page lists a total file size of tens of terabytes. Many teams can download a smaller dataset quickly, but few can casually stage, index, and test this release.
The companies most able to run the complete benchmark will be database vendors, cloud providers, large enterprises, and research institutions. Smaller teams may depend on published results or sampled subsets, recreating part of the trust problem.
A shared hosted leaderboard could improve access, but it would introduce governance questions. Someone must define hardware profiles, approve configurations, verify submissions, update database versions, and prevent selective reporting.
Sixth, the release does not measure complete application quality. Production AI search often includes document parsing, chunking, query rewriting, hybrid fusion, reranking, caching, authorization, and answer generation. A failure in any stage can dominate user experience.
These limitations do not argue for smaller benchmarks. They argue against treating one large benchmark as a complete purchasing framework.
Buyers should combine three layers of evidence. A public test can expose broad scaling behavior. A private workload test can reproduce local distributions and filters. An end-to-end evaluation can measure whether users receive correct, attributable answers.
That standard is demanding, but AI search increasingly supports decisions where missing one document matters. A benchmark should make those tradeoffs visible instead of compressing them into one throughput score.
Three Signals Will Show Whether Qdrant’s Bet Works
The release succeeds only if independent teams use it to produce comparable evidence, find problems, and improve the testing process.
The first signal is reproducible third-party results. Researchers and database vendors need to publish complete runs using Qdrant-FineWeb-10B or an auditable subset. Those reports should include hardware, software versions, index parameters, ingestion time, memory, recall, and p99 latency.
Matched recall will be particularly important. Comparing throughput at different accuracy levels can make a faster system look better without revealing what it omitted. Results should present performance across several recall targets.
If independent teams reproduce results across Qdrant, Milvus, Elasticsearch, pgvector, and other systems, the release will strengthen the case for open measurement. If configurations remain incomplete or prohibitively expensive, its influence will narrow.
The second signal is correction activity around the data and tooling. The numerical difference disclosed in the dataset card provides an immediate test. A timely fix, versioned artifacts, checksums, and documented changes would reinforce confidence.
Researchers should also inspect query composition, duplicates, language coverage, filter distributions, and the difficulty of the nearest-neighbor tasks. A large row count does not guarantee a balanced evaluation.
Supernova’s contribution history matters here. External bug reports, pull requests, backend integrations, and alternative configurations would show that it functions as community infrastructure. Limited outside activity would leave it closer to a vendor-maintained demonstration.
The third signal is whether buyers change what they request from vendors. The most durable result would not be a single leaderboard position. It would be a stronger procurement standard for AI search.
Enterprise teams should ask vendors to report exact recall alongside latency. They should request ingestion and index-build measurements, not only steady-state query speed. They should also test selective filters and failure recovery.
Public benchmark results can narrow a shortlist, but organizations still need local evidence. A retailer searching product catalogs, for example, may care about inventory filters and high retrieval depth. A legal team may prioritize tenant isolation, citations, and exact terminology.
The Qdrant FineWeb 10B benchmark gives both groups a better reference point. It shows what becomes measurable when someone pays the substantial cost of creating exact answers at internet scale.
Qdrant also gains strategic benefits. The company gets to influence which measurements buyers consider important, while placing its preferred language of recall, openness, and reproducibility at the center of the discussion.
That does not invalidate the work. Standards often begin with an interested participant investing resources that others would not. The safeguard is transparent governance and credible external replication.
Competitors now face a useful choice. They can run the workload and publish results, challenge its assumptions with evidence, or contribute alternative datasets and tests. Silence will make opaque performance claims harder to defend.
For developers, the immediate action is not to download tens of terabytes without a plan. Start by identifying which question needs an answer: algorithmic recall, database scaling, retrieval relevance, or end-to-end application quality.
Then choose the smallest test that preserves the relevant difficulty. Use public ground truth where it fits, but keep private queries and documents in the final evaluation. Record every configuration needed to reproduce the result.
AI search benchmarking will not be fixed by scale alone. Yet scale removes an increasingly convenient excuse. The Qdrant FineWeb 10B benchmark now gives the industry a public way to test claims that previously depended on private data and private infrastructure.
The next few months should reveal whether the community treats it as a shared laboratory or another vendor artifact. Developers and buyers should watch the replications, corrections, and competing submissions, then demand the same transparency from every AI search provider they evaluate.



