Qdrant

We just released Qdrant 1.19.1, a patch release with some pretty significant performance improvements under the hood. Quantized HNSW search is now around 1.5-2.5× faster, thanks to software prefetching, with TurboQuant and other quantized datatypes seeing some of the biggest gains. We also reworked the 4-bit TurboQuant SIMD implementation, improved batched HNSW searches, and made several optimizations to reduce unnecessary work during search. And the improvements aren’t limited to search. Payload-heavy shard transfers are now 1.5× faster, along with improvements to deletion checks, memory reporting, and other parts of the system. A lot of this work isn’t visible as a new feature on the surface, but it can make a meaningful difference when you’re running Qdrant at scale. Full release here: https://lnkd.in/dUTtCutm

3 years ago, I released a 1M OpenAI embeddings dataset that helped accelerate HNSW adoption and still gets ~2K downloads/month. Today many of our customers run vector search at billion+ scale. So we just released 10B Real Embeddings (10,000x larger) to push the community and research forward. Really excited to see what people build with it! 🧑🚀🚀

Most search benchmarks lie to you. Not maliciously. But when the ground truth is synthetic, the queries are hidden, and the whole thing runs on a paywalled service you can't inspect, you're not testing search. You're testing marketing. To fix that, we're releasing three things today. Qdrant-FineWeb-10B: 10 billion documents, dense and sparse vectors, over 50 TB of vector and meta data, with exact top-1000 ground truth computed by brute force across the full 10-billion-vector space for 120,000 queries. Over a quadrillion distance computations. No approximation, no shortcuts. We ran that math once, so you don't have to. Two more datasets, built in the same way. PubMed-Multi-Vector, for hybrid retrieval: dense, sparse, and ColBERT-style multi-vector representations over the same corpus, 8.37 billion multi-vector tokens. Coyo-Vector-Embeddings, for multimodal search: image-caption pairs projected through a 2048-dimensional vision-language encoder. Supernova: the framework that generated all of it, fully open source. Embedding generation, GPU-native brute-force ground truth, ingestion, and stress testing, all driven by YAML, running on your own infrastructure through SkyPilot, across AWS, GCP, Azure, Kubernetes, or Slurm. Not gated. Not dependent on Qdrant or anyone else's stack. Feel free to plug in your search engine for benchmarking. Why give this away? Computing exact ground truth at this scale is genuinely expensive, quadrillions of distance calculations, and that cost is exactly why nobody had done it publicly before. We absorbed it once, with compute from Vultr, so the rest of the field doesn't have to. If your production system needs 95%+ recall at depth 1000 and sub-100ms p99, and the only thing you've ever validated it against is a million synthetic vectors, now you can check for real. Real data, real scale, math you can verify yourself. The announcement: https://lnkd.in/drBjYjWH Datasets and Supernova are linked in the comments. Congrats to the Qdrant Labs team! 🙌 HUGE thanks to Vultr for providing compute power to generate embeddings and to Hugging Face for hosting the datasets! 🙏

Vector search benchmarks were not good enough: synthetic data, hidden queries, tiny corpora. So we built what was missing and gave it away. Production workloads no longer live at 1 million vectors. Enterprises index billions and search them at high throughput with tight tail latency, yet public benchmark datasets stop far short of that, and exact ground truth at scale is rare because computing it means brute-force comparisons across the entire corpus. Over a quadrillion of them, at 10 billion documents. We took direct action. In partnership with Vultr, we absorbed the cost, and today the results belong to the community, free on Hugging Face: https://lnkd.in/djPragHJ - Qdrant-FineWeb-10B, the largest open-source vector search benchmark dataset: 10 billion FineWeb documents with dense and sparse vectors from gte-multilingual-base (24.47 TB of vectors, 28.66 TB of text and metadata), with exact top-1,000 ground truth for 120,000 dense, sparse, and filtered queries - PubMed-Multi-Vector: dense, sparse, and ColBERT-style multi-vector representations of one corpus, for benchmarking hybrid retrieval with the data held constant - Coyo-Vector-Embeddings: multimodal image-caption embeddings at 2,048 dimensions And so none of it rests on a vendor claim. 𝐒𝐮𝐩𝐞𝐫𝐧𝐨𝐯𝐚, the open-source tool that we used, is public: https://lnkd.in/dvYCxjEt. It handles embedding generation, GPU-native brute-force ground truth, cluster loading, and evaluation, scaling across clouds and HPC clusters via SkyPilot. Vultr provided the compute, SkyPilot distributed it, and Hugging Face hosts the datasets. The era of 1-million vector datasets and synthetic approximations is over. Real data, real ground truth, open tooling. Full writeup here: https://lnkd.in/dWcMPN4q

What happens when you put a room full of vector search researchers together for a few hours and let them show what they’re actually working on? We’re hosting Vector Space Stream, a free virtual stream on September 17, bringing together Qdrant Engineers to share the latest work across vector search. The agenda goes from token-native storage and vector compression to robotic memory, new embedding geometries, asymmetric dual encoders, and the many tuning knobs of hybrid search. The sessions focus on the research itself: motivations, challenges, learnings, and outcomes, with NO marketing pitches. Check out the full agenda below! September 17 · Virtual · Free Register here: https://lnkd.in/gEJZG-zJ

We get asked a lot why Qdrant exposes k for Hybrid Search as a tunable parameter instead of just picking a good default and moving on. This is why. Our default is k=2. The paper everyone cites when they say "we use RRF" uses 60. Same formula, wildly different behavior, and it's the kind of gap that's easy to ship past without ever noticing. At k=2, rank 1 in a prefetch carries 5.5x the weight of rank 10 once fused. At k=61 (the zero-based equivalent of the paper's 60), that drops to 1.15x, so just getting retrieved by dense or sparse starts to matter almost as much as where it landed. On one of our test sets, switching from k=2 to k=61 changed the top hybrid search result on 42% of queries. That's not a rounding error. That's a different product experience, shipped silently. What we found across five datasets: with roughly one relevant document per query, low k wins. With tens or hundreds, high k wins. There's no universal right answer, which is exactly why we didn't want to bury this behind a fixed default and call it solved. The same goes for RRF vs. DBSF, our distribution-based fusion method. RRF only sees rank, so a document that barely won its prefetch scores identically to one that crushed it. DBSF keeps the actual score gap. It beat default RRF on 3 of 5 datasets here, and lost on the other 2 within noise. We'd rather hand you both and the measurement method than pretend one is always right. Full methodology: https://lnkd.in/d_EtYB5v

Hybrid search consistently improves retrieval quality, but the way you configure the fusion matters. Across 5 public datasets we tested, hybrid retrieval outperformed both dense and sparse retrieval on 4, with gains of roughly 2–4% in nDCG@10. The exception was DBPedia-entity, where dense retrieval remained slightly ahead. The interesting part is what happens after enabling hybrid search. RRF and DBSF use different signals: RRF looks at rank, while DBSF also accounts for the distribution of retrieval scores. In these experiments, DBSF performed better than default RRF on 3 of 5 datasets. But that’s not a universal rule. It’s better to test both and see which works best for your use case. For RRF, 'k' is another important lever. With around one relevant document per query, 'k=2' or '5' worked best on these datasets. With tens or hundreds of relevant documents, 'k=20' or '61' performed better. Weights should be tuned only after settling on 'k'. Thanks to Dylan Couzon for sharing these findings. The full article goes into the benchmarks, score behavior, tuning ranges, and validation methodology, check out here: https://lnkd.in/d8AdJmaj

Once your collection outgrows RAM, the kernel starts evicting vector pages. That's what quantization is for: TurboQuant (Qdrant's method that rotates each vector before compressing it) keeps a compressed copy in RAM and lets the full-precision originals live on disk. But rescoring, the step where Qdrant rereads those originals to sharpen the top candidates, is basically free while they're still cached, and brutal once they're not. 4.1 ms at 12 GiB. 43.4 ms at 4 GiB. Same query, same TurboQuant settings, just less headroom. The part I didn't expect: whether that pain is worth it depends entirely on how aggressive your bit depth is. At TurboQuant's bits4 (the recommended default, 8x compression), rescoring bumped Recall@10 from 0.918 to 0.993, but across 200 held-out queries it didn't move the actual ranked results (nDCG@10) at all. So at that depth, you could arguably skip it. At bits1 though, rescoring isn't a nice-to-have, it's the only thing standing between you and a search that's wrong 40% of the time (0.605 → 0.951 Recall@10 with one pass). And past oversampling 1, you're mostly just paying for disk reads that don't buy you anything (0.951 → 0.977 → 0.988 going from 1 to 4). Basically: know your Quantization bit depth before you decide rescoring is optional, and measure at the memory cap you'll actually deploy with, not the one on your laptop. Full setup steps and memory-placement config: https://lnkd.in/dJ8Nr7fQ

Before you tune anything in a vector search stack, check a handful of settings that fail silently. They produce no errors, so every A/B test that follows measures a broken setup rather than a real trade-off. Two clear examples with Qdrant: A sparse vector missing its IDF modifier treats rare terms the same as common ones. BM25’s avg_len is left at the default (256 in Qdrant), systematically misjudging document length. Across five test datasets, the correct stemmed value ranged from 35.3 to 151.4—15–43% lower than a naïve word count would suggest. Neither raises an error. Both quietly render every downstream comparison meaningless. Your labeled query set is equally decisive. Fusion tuning moved nDCG@10 by only 0.012–0.038 across their datasets. With 25 labeled queries, the 95% confidence interval was ±0.047—wider than most of the gains. At 50 queries, it narrowed to ±0.035, enough to resolve the 0.038 gain in 93% of resamples but only 7–38% of the time for gains under 0.02. If you’re under-labeled, the honest move is to report the change as unresolved rather than claim a win. Sharding adds another silent failure mode. RRF or DBSF fusion placed at the root of a query runs once, after all shards return candidates. Nested inside a prefetch, it runs per shard, fusing only local candidates, and the ranking changes with shard count. Nothing warns you which behavior you’re getting. The full piece orders the checks by cost—indexing status, payload indexes, fusion placement, score_threshold—before you touch fusion constants or add a reranker: More to read: https://lnkd.in/dQNpKHwG

What if a warehouse robot could search an entire product catalog without ever connecting to the network? Rahul Sharma built an offline visual search system for apparel robotics using Qdrant Edge + MobileCLIP2. The key idea: keep both the vision model and vector index on the robot, so it can recognize products in real time even when Wi-Fi is unreliable. He also uses Qdrant’s multivectors + MAX_SIM to store multiple views of the same product, making retrieval more robust to crumpled, folded, or partially visible items. Read the full article: https://lnkd.in/gKnKzqv3 #Qdrant #VectorSearch #Robotics #EdgeAI #ComputerVision #AI