What Qdrant Actually Is (From Someone Who Runs It in Production)

I have been running Qdrant in production since early 2025. Before that, I went through Pinecone (great but expensive), Weaviate (good hybrid search, the GraphQL API drove me crazy), and Chroma (fine for prototypes, fell apart at 500K vectors).

Qdrant is a vector database. It stores embedding vectors — those lists of 768 or 1536 floating-point numbers that represent the "meaning" of text, images, or audio — and lets you search through millions of them in milliseconds. It is written in Rust, ships as a single binary, and runs in one Docker container.

The reason I stuck with it: I moved a client's RAG pipeline from Pinecone Standard ($700/mo) to a self-hosted Qdrant instance on a $40/mo Hetzner VPS with 8M vectors. Search latency went from 45ms to 18ms. Monthly cost went from $700 to $40. That is a 94% cost reduction with better performance. The client renewed for 12 months.

---

The Features You Will Actually Use

HNSW Indexing — The Engine

Qdrant uses HNSW (Hierarchical Navigable Small World) for approximate nearest neighbor search. Without going into the math: it builds a graph structure where similar vectors are connected, and search walks the graph instead of scanning everything.

Real numbers from my deployment: 5M vectors at 1536 dimensions. Index build time: 12 minutes. Search latency: 18ms average at 95th percentile. Memory usage: 11GB (with Scalar quantization, down from 34GB without).

The default HNSW parameters (m=16, ef_construct=100) work for collections under 2M vectors. Above that, you want m=8 and ef_construct=200. Too many people skip this and wonder why their RAM usage is through the roof.

Payload Filtering — The Underrated Feature

Most vector databases can search. Few can search AND filter efficiently. Qdrant's payload filtering lets you attach metadata (dates, categories, user IDs, status flags) to each vector and filter by them during search.

Real example: I built a legal document search system. Each vector has payload fields like jurisdiction: "California", document_type: "contract", date: "2024-03-15". A query like "find similar contracts about non-compete clauses filed in California after 2023" runs as: vector search for "non-compete clause" + payload filter {jurisdiction: "California", date: {"$gte": "2023-01-01"}}.

This runs in a single query, not two. Search first, filter after. The latency with 4 filter conditions on 8M vectors is 22ms. Try doing that with post-search filtering in application code and you will be waiting 200-400ms.

Quantization — How I Cut Memory by 80%

Qdrant supports three quantization modes — Scalar, Product, and Binary. I use Scalar quantization on almost everything. It converts 32-bit floats to 8-bit integers per dimension. For 1536-dimension vectors, that drops each vector from 6.14KB to 1.54KB.

On an 8M-vector collection: without quantization = 49GB RAM. With Scalar quantization = 12.3GB RAM. Recall drops from 0.997 to 0.982. For a semantic search use case, losing 1.5% recall to save 75% on RAM is a trade worth making every time.

Binary quantization is even more aggressive (1 bit per dimension), but I only use it for initial filtering — binary search to narrow from 10M to 50K candidates, then exact search on the 50K. This gets you sub-10ms latency at billion-vector scale if you architect it right.

Real-Time CRUD — Not a Batch-Only Database

This matters more than people think. Pinecone and many managed services treat vectors as a batch upload — you index once, then query. Qdrant supports real-time inserts, updates, and deletes without rebuilding the index.

Practical use case: I built a customer support chatbot where new support tickets are vectorized and inserted within 5 seconds of submission, so the RAG system can reference tickets from this morning. Client A's dashboard shows tickets from Client B because Pinecone's index is 2 hours stale? That gets you fired. Qdrant's real-time writes prevent that.

---

What Qdrant Is Bad At (Honest Assessment)

1. No Built-In Embeddings

This is the #1 thing that trips up newcomers. Qdrant stores and searches vectors. It does NOT generate vectors. You need a separate embedding model — OpenAI's text-embedding-3, Cohere Embed, sentence-transformers, whatever. This means your pipeline has two moving parts: an embedding service and Qdrant. If the embedding service goes down, Qdrant is useless. Plan accordingly.

2. Documentation Assumes Too Much

The docs are technically correct but written for people who already understand vector search. If you do not know what ef_construct does or why m=16 is the HNSW default, the docs will not teach you. You will need blog posts, YouTube tutorials, and trial-and-error. Budget 3-5 hours to get comfortable before your first real deployment.

3. Multi-Tenancy Is Manual

If you need to serve 50 clients from one Qdrant instance with strict data isolation (Client A must never see Client B's vectors), you have two options: (a) a separate collection per client (clean but resource-heavy), or (b) a single collection with client_id in the payload and filter on every query (efficient but you must never forget the filter — one bug and you have a data leak). Neither is as clean as Pinecone's built-in namespace isolation.

4. The Cloud Free Tier Is Useless

1GB of storage on the free tier is enough for about 800K vectors at 768 dimensions, or 400K at 1536. That is a prototype, not a product. You will be on the paid plan from day one of anything real. The pricing after that is reasonable ($25/mo for 5GB), but the jump from free to paid is jarring.

5. No Built-In Migration Tools

If you are coming from Pinecone, Weaviate, or Milvus, you are writing custom export-and-reimport scripts. There is no "Import from Pinecone" button. Budget 2-3 days for a production migration: export from source, transform the format, batch-insert into Qdrant, verify recall parity, switch DNS. It is not hard, but it is tedious and error-prone.

---

How Much Money Can You Make With Qdrant?

Let me break this down with real numbers from what works.

Model 1: RAG Consulting ($5K-$15K Per Project)

Companies with large document repositories — law firms, hospitals, insurance companies — need semantic search over their internal data. They do not care about vector databases. They care about "my paralegals spend 12 hours a week searching through old case files."

Your pitch: "I will build you a search system that finds relevant documents in under 2 seconds." Your tech: FastAPI + LangChain + Qdrant self-hosted on their infrastructure. Your cost: near zero (Qdrant is open source). Your bill: $8K-$15K per engagement.

At 6 projects a year, that is $48K-$90K. Qdrant's open-source nature means your infrastructure cost is just the server, which the client pays for anyway. Compare that to using Pinecone where $700/mo comes out of YOUR margin on a fixed-price project.

Model 2: Managed Vector DB Hosting ($300-$800/Mo Per Client)

Small businesses do not want to run Docker. They want "the search just works."

Set up a dedicated server (Hetzner AX52, €59/mo = about $64). Run Docker with individual Qdrant instances per client (separate containers on different ports). Charge $300-$800/mo per client for "managed vector search."

At 10 clients: $3K-$8K/mo revenue on $264/mo infrastructure costs (one server + one backup server). Your job: monitor the Prometheus dashboard, run snapshot backups to S3, apply Qdrant version updates quarterly. This is 5-8 hours of work per month.

Model 3: Pinecone-to-Qdrant Migration ($2K-$5K Per Migration)

Pinecone Standard at 2M vectors costs $700/mo. A company with 5M vectors on Pinecone Enterprise is paying $1,500+/mo. The same workload on self-hosted Qdrant: $40/mo.

Your migration service: audit their current Pinecone setup, export all vectors, transform the metadata format, import into Qdrant, run recall comparison tests, cut over their application. Charge $2K-$5K one-time. The client saves $660-$1,460 per month forever. They will say yes.

At 2 migrations per month: $4K-$10K/mo. The work is 80% Python scripting (export/transform/import) and 20% client communication.

Model 4: Domain-Specific SaaS ($29-$99/Seat)

Build a vertical search product on top of Qdrant. Examples: legal precedent search for small law firms, medical literature search for clinics, e-commerce product recommendation for Shopify stores.

Charge per seat: $29-$99/month. At 50 seats: $1,450-$4,950/mo. Infrastructure cost: the Qdrant instance costs $40-$100/mo at this scale. The rest is margin.

The moat here is not the vector DB — it is the domain-specific data pipeline, the UX tailored to that industry, and the relationships you build with customers.

---

Qdrant vs The Alternatives

FeatureQdrantPineconeMilvusWeaviate
Self-hosting✅ Single Docker container❌ Managed only✅ Requires K8s cluster✅ Single Docker container
Entry cost (1M vectors)$0 (self-hosted)$70/mo$200+/mo (K8s infra)$0 (self-hosted)
Real-time writes✅ Yes✅ Yes (paying tiers)✅ Yes✅ Yes
Built-in embeddings❌ No❌ No❌ No✅ Yes (vectorizer modules)
Quantization✅ 3 modes❌ No✅ Multiple modes✅ PQ only
Payload filtering✅ Excellent✅ Good✅ Good✅ Good (GraphQL)
Hybrid search✅ (dense+sparse)✅ (dense+sparse)✅ (dense+sparse)✅ (bm25+vector)
Learning curveMediumLowHighMedium
Best forSolo consultants, small teams, cost-sensitive deploymentsTeams that want zero opsEnterprise-scale, billion-vector systemsTeams that want all-in-one (DB + embeddings + hybrid search)

---

Getting Started (From Someone Who Messed It Up the First Time)