Hey everyone! 👋 I've been living in the LlamaIndex ecosystem for my latest project, and as part of that, I recently made a pretty significant infrastructure switch. I wanted to share my experience in case anyone else is evaluating their vector database layer.
We initially built our prototype using **Weaviate** as our vector store. It worked well for getting off the ground—the schema flexibility was great, and the built-in modules felt powerful. However, as we started to scale our proof-of-concept and prepare for a larger beta rollout, we began running into some operational and cost concerns. The memory footprint for our container was higher than we'd hoped, and while we were on a cloud instance, the pricing for a fully-managed service felt like it would add up quickly for our use case.
So, I led a sprint to evaluate alternatives and we landed on **Qdrant**. The migration itself was surprisingly smooth, thanks largely to LlamaIndex's abstractions. Here’s a quick rundown of what we’ve observed:
**The Good:**
* **Performance:** Our query latency dropped noticeably, especially for complex graph retrievers. We're seeing more consistent sub-100ms times for k-NN searches on our dataset (~500k embeddings).
* **Resource Efficiency:** The Qdrant container runs leaner on our Kubernetes cluster. We're seeing about 30% lower memory usage for a comparable load.
* **Cost:** Self-hosting Qdrant is straightforward, and their cloud offering's pricing model (based on compute units) seems like it will be more predictable for us long-term.
* **Simplicity:** The API feels very direct and aligns well with LlamaIndex's patterns. Setting up filtering using their payload system was a breeze.
**The Not-So-Good (or just Different):**
* We lost some of the "batteries-included" feel of Weaviate. For example, we had to be more explicit about things like vector indexing configuration.
* The ecosystem around Weaviate (like the modules) is broader. We're now handling some things (like specific text preprocessing steps) in our own ingestion pipeline instead of at the DB layer.
* The learning curve wasn't steep, but it did require a solid day of rethinking our data models and ingestion flow.
From a **LlamaIndex-specific workflow**, the switch was mostly about changing the `StorageContext` and `ServiceContext` setup. Our `VectorStoreIndex` creation and query engines worked seamlessly afterward. The consistency there was a huge win.
**My big question for the community:** Has anyone else made a similar switch, or perhaps gone from Qdrant to something else? I'm particularly curious about your experiences with filtering performance and hybrid search approaches as the dataset grows. I'd love to compare notes!
keep building
keep building