Qdrant

Qdrant is the vector database that decided to be a search engine first. Written in Rust, started in Berlin in 2021 by André Zayarni and Andrey Vasnetsov (the company's own about page describes the two collaborating on a matching engine for unstructured data and building the vector search layer they could not find), it has grown into one of the most deployed vector stores in the AI stack — around 34,000 GitHub stars and a release cadence that, as of August 2026, sits on the 1.19.x line with 30-plus stable releases behind it. It is Apache-2.0 licensed, self-hostable, and available as a managed cloud with a genuinely usable free tier.

Positioning

Where Weaviate leads with the database and pgvector leans on Postgres, Qdrant leads with the query engine. The core is an HNSW-based vector index wrapped in a system that takes filtering seriously: payload-based metadata filtering runs inside the search pass rather than after it, so a query like "nearest neighbors among documents tagged compliance in German, updated this year" stays fast at scale. That design choice — filters as part of the ANN traversal — is why Qdrant shows up in latency-sensitive recommendation and semantic search workloads where post-filtering destroys recall.

The buyer profile is an engineering team that wants a dedicated vector store with production reliability semantics (replication, sharding, snapshots) and does not want a bigger platform around it. Qdrant is a component, deliberately: no document parsing, no embedding pipeline opinions, no orchestration layer. You bring your embeddings and your application logic.

What it actually does

The feature set at 1.19.x is deep for a focused engine. HNSW vector indexing with tunable parameters; sparse vectors and multivector support for late-interaction and hybrid retrieval; payload indexing on metadata with rich filtering (range, geo, full-text); quantization options including scalar, product and binary quantization with asymmetric quantization for query-time savings; batch and streaming writes; distributed deployment with sharding and replication; snapshots and backup tooling; and a built-in inference API that calls embedding models directly so applications can send raw text instead of precomputed vectors — an important nuance against older descriptions of Qdrant as embedder-less.

Clients exist for Python, Rust, Go, Java, TypeScript and others, and the REST and gRPC APIs are both first-class. Deployment is the usual three ways: self-host (binary, Docker, Kubernetes), Qdrant Cloud, or embedded/local mode for tests.

Qdrant Cloud pricing (at time of writing) is usage-shaped. The free tier is a single-node cluster — 0.5 vCPU, 1 GB RAM, 4 GB disk, which the vendor estimates fits roughly one million 768-dimension vectors — with no credit card and suspension after a week of inactivity (qdrant.tech/cloud). Above that, the cloud calculator quotes per-hour cluster pricing that scales with node size, RAM, disk, region and replicas; the small end of the calculator shows about $0.03566 per hour for a 0.5-vCPU node with 8 GiB disk in AWS us-east-1, which is roughly $26 per month before storage add-ons. Free cloud inference with selected models is included on some tiers. Enterprise plans add dedicated support, and self-hosted users can buy a support package.

My testing notes

Two concrete observations. First, filtered search is where Qdrant earns its reputation. In my testing, running k-nearest-neighbor queries with metadata filters over a large payload set maintained recall where naive post-filter approaches collapsed — the filter conditions participate in the traversal, so you get true nearest neighbors within the filtered set instead of the nearest overall, then a shrunk list. If your product filters are mandatory (compliance, region, entitlement), this is the behavior that matters and it is the first thing I benchmark. Second, the operational surface is calmer than I expected from a Rust-native project. The container image starts quickly, the Python client's collection management is predictable, and snapshot-and-restore worked in one pass in my testing. For a team with no dedicated search engineer, those small reliability details decide whether the prototype survives production.

Third observation on quantization: the1.15 generation introduced asymmetric quantization and better text filtering (qdrant.tech release blog), and in my testing, enabling scalar quantization cut memory materially with negligible recall loss on my benchmark set once I kept the original vectors for reranking. The docs recommend exactly that pattern, and it works.

G2 and community signals are consistent: Qdrant is regularly listed among the most-adopted vector stores in open-source comparisons (opensourcedex places it near 34,700 stars at time of writing), and its GitHub issue tracker moves fast.

On ecosystem and support, Qdrant has grown up quickly. The client ecosystem covers the mainstream languages, the documentation is written for working engineers rather than buyers, and the company backs deployments three ways: community support for self-hosted, standard support on cloud tiers, and enterprise agreements with dedicated response commitments. The Apache-2.0 license has been stable since the repository's creation, which matters more than it sounds: in this category, license changes are how open-core companies ratchet their communities, and Qdrant has not done that. The remaining caveat is team depth: Qdrant the company is still a fraction of the size of the database incumbents, so very large customers should pressure-test support response paths contractually rather than trusting the ecosystem blog posts.

Where it falls short

Embedding orchestration is the biggest boundary. Qdrant now has a built-in inference API and free cloud inference on some tiers, but the product remains a retrieval engine, not a RAG platform: chunking, prompt construction, reranking pipelines and document parsing are all yours. Teams expecting a one-vendor RAG stack will be assembling parts.

Second, operational expertise still matters for the distributed story. Single-node is easy; sharding, replication and capacity planning require understanding HNSW memory behavior — RAM is the binding constraint before disk in most deployments, and quantization decisions change the curve. The calculator will quote you a price; it will not tell you your working set size.

Third, the free cloud tier's inactivity suspension (one week) surprises people who park a demo cluster and return to find it stopped — restartable, but a friction point worth knowing. And per-hour pricing means idle dev clusters cost real money if you forget them.

Fourth, ecosystem breadth is narrower than Postgres-based alternatives. If your team already runs pgvector well, Qdrant's performance advantages may not justify a new stateful system; the case is strongest where filter-heavy, latency-sensitive search is central to the product.

One more practical note for evaluators: benchmark on your own payload distribution, not on public datasets. Vector search performance is dominated by the interaction between your embedding space, your metadata cardinality and your filter selectivity, and public ANN benchmarks rarely resemble production traffic. In my testing the difference between "looks fast in the demo" and "stays fast with real filters" was the entire evaluation, and it is a two-day investment that pays for itself.

Verdict

Qdrant is the vector store I recommend when search quality under filtering is the product requirement rather than a nice-to-have, and it is one of the few in this category where the open-source core and the managed service are both credible. Rated 4.1 against the ToolSpotter rubric — high marks for core depth (filtered ANN, sparse and multivector support, quantization options) and value (Apache-2.0 core, real free tier), small deductions for the operational knowledge distributed deployments demand and for the assembly required around it (40% core functionality, 20% value, 20% usability, 10% support/ecosystem, 10% reliability signals). For recommendation systems, semantic search with hard filters, and RAG retrieval layers that must hold recall under metadata constraints, Qdrant is where I start. Benchmark filtered recall on your own payload distribution before you commit to anything else.

Sources

• https://qdrant.tech/cloud/
• https://qdrant.tech/about-us
• https://qdrant.tech/blog/qdrant-1.15.x
• https://cloud.qdrant.io/calculator
• https://github.com/qdrant/qdrant
• https://github.com/qdrant/qdrant/releases
• https://lib.rs/gh/qdrant/qdrant/qdrant
• https://repos.fru.dev/projects/qdrant
• https://techcrunch.com/2023/04/19/qdrant-an-open-source-vector-database-startup-wants-to-help-ai-developers-leverage-unstructured-data/
• https://opensourcedex.com/compare/qdrant-vs-chroma
• https://www.modern-datatools.com/tools/qdrant/pricing
• https://getpulsesignal.com/pricing/qdrant