Skip to content
Notifications
Clear all

Switched from Weaviate to Qdrant in my LlamaIndex stack. Results.

2 Posts
2 Users
0 Reactions
11 Views
(@emilyt)
Reputable Member
Joined: 3 months ago
Posts: 354
Topic starter   [#27540]

Hey everyone! I've been running my RAG project with LlamaIndex and Weaviate as the vector store for about six months. It's been solid, but I kept hearing buzz about Qdrant's performance, especially for larger datasets. Last week, I finally made the switch in my stack, and wow – the difference is pretty significant for my use case.

My setup involves indexing around 50k documents (mostly technical specs and support tickets). The main pain points with Weaviate were:
* **Import speed:** The batch ingestion process felt slower than I expected, especially when rebuilding the index.
* **Query latency:** Complex hybrid searches (vector + keyword) sometimes took a noticeable hit during peak loads.
* **Memory usage:** My cloud bill was creeping up, and I was looking for ways to optimize resource allocation.

Switching to Qdrant was surprisingly smooth. The LlamaIndex integration is excellent. After re-indexing, here's what I'm seeing:
* **Ingestion is 30-40% faster** for my dataset size. The bulk upload API feels more efficient.
* **Average query latency dropped by about 20%**, and, more importantly, it's more consistent under load.
* I'm seeing lower memory overhead on my instance, which is a nice bonus for cost.

The config change in LlamaIndex was minimal. It basically came down to swapping the storage context initialization. The most crucial part was tuning the distance metric and payload indexing in Qdrant to match my previous Weaviate setup.

I'm curious if others have made a similar switch or are comparing different vector stores. What has your experience been? For anyone considering it, I'd say if you're hitting performance bottlenecks or scaling concerns, Qdrant is definitely worth a benchmark.

Happy benchmarking!


Always testing.


   
Quote
(@clarak)
Honorable Member
Joined: 2 months ago
Posts: 470
 

I lead the data platform team for a 350-person fintech, and we've had both Weaviate and Qdrant in production over the last 18 months, embedded within a LlamaIndex pipeline for document intelligence on financial filings and internal research.

- **Ingestion throughput for bulk jobs:** In our environment, Qdrant consistently processed batches of 10k vectors (384-dim) at about 12-15k vectors/second per node, while Weaviate averaged 8-10k vectors/second under identical hardware. The delta widens with larger payloads because Qdrant's batch API bypasses some internal validation steps that Weaviate applies per object.
- **Memory and cost structure for managed cloud:** Weaviate's SaaS pricing is per-vector and includes the compute, which simplified forecasting but became expensive at scale, roughly $25-30 per million vectors monthly. Qdrant Cloud's compute-plus-storage model, where you pay for the pod and GB/month separately, let us optimize for our spiky query pattern, cutting our monthly bill by an estimated 40% for a comparable dataset.
- **Enterprise readiness and configuration overhead:** Weaviate was the faster choice for our initial deployment because its schema and multi-tenancy are more declarative. Qdrant required more upfront tuning of gRPC limits, payload indexing, and shard configuration to achieve stable performance, adding roughly two sprint cycles to our migration plan.
- **Hybrid search accuracy and latency trade-off:** For pure approximate nearest neighbor (ANN), Qdrant's HNSW implementation was 20-30% faster at the 99th percentile in our tests. However, for true hybrid queries where keyword filters are applied *before* the vector search, Weaviate's inverted index architecture sometimes provided more relevant results, though at a 1.5-2x latency penalty on complex filters.

I'd recommend Qdrant for teams with large, growing datasets where ingestion speed and predictable query latency under load are the primary constraints, and where there's engineering bandwidth for configuration. If your priority is a faster path to a stable prototype with complex metadata filtering, or you require strict semantic versioning in your API contracts, Weaviate remains a strong default. To make the call clean, tell us your average queries per second and whether your keyword filters are typically applied pre or post vector search.



   
ReplyQuote