Qdrant

Getting started means creating a collection with a defined vector size and distance metric, then upserting points (each a vector plus an optional JSON payload and an id) -- the fastest path is the official Docker image (docker run qdrant/qdrant) for local development, or Qdrant Cloud for a managed cluster.

Practical Details

Vector size and distance metric are set at collection creation and effectively fixed afterward, so confirming your embedding model's actual output dimensionality (and whether it expects cosine or dot product similarity) before creating the collection avoids a rebuild later. Payload indexes (on fields you'll filter by) need to be created explicitly -- they aren't automatic -- which is a common gap when filtered search performs worse than expected.

Actionable Considerations

1. Confirm your embedding model's output dimensionality and intended distance metric before creating the collection, since both are effectively fixed afterward.
2. Create payload indexes explicitly for any field you plan to filter on, rather than assuming filtering works efficiently by default.
3. Run a small pilot with representative data volume before committing to a production shard/replica configuration.
4. Use the Docker image for local development and prototyping before deciding between self-hosted Kubernetes and Qdrant Cloud for production.

Qdrant scales primarily through sharding (splitting a collection's points across multiple shards) and replication (copies of each shard for fault tolerance and read throughput), both configurable per collection at creation time. Query performance is governed by the HNSW index parameters -- m (graph connectivity) and ef_construct/ef (search-time candidate list size) -- which trade recall against latency.

Practical Details

For collections too large to fit in memory, Qdrant supports on-disk storage with memory-mapped payload and vector indexes, letting you serve larger-than-RAM datasets at some latency cost. Scalar, product, and binary quantization reduce memory footprint further by compressing vectors, which matters more as collection size grows than raw shard count alone.

Actionable Considerations

• Set shard and replication factor based on expected data volume and fault-tolerance needs at collection creation, since shard count can't be changed later without re-sharding.
• Tune HNSW's ef parameter at query time to trade search speed for recall as your workload's accuracy requirements become clearer.
• Apply quantization (scalar, product, or binary) when memory becomes a constraint before defaulting straight to adding more nodes.

Qdrant's access control is API-key based -- Qdrant Cloud supports read-only and read-write API keys scoped to specific collections, while self-hosted deployments can enable API key auth via configuration (it's off by default on a fresh local instance, which matters for anything beyond local testing).

Practical Details

TLS for data in transit and encryption at rest are available (the specifics depend on whether you're self-hosting or using Qdrant Cloud, where storage-layer encryption is handled by the underlying cloud provider). Because a self-hosted instance has no auth enabled out of the box, exposing it on a public network without configuring an API key is a genuine and common misconfiguration.

Actionable Considerations

1. Enable API key authentication explicitly on self-hosted Qdrant before exposing it beyond localhost or a private network.
2. Use scoped, collection-specific API keys in Qdrant Cloud rather than a single broad key across every collection.
3. Confirm TLS is enforced for client-to-server traffic, especially for any deployment reachable outside a private VPC.
4. Rotate API keys periodically and immediately after any team member with access leaves.

Data in Qdrant is organized into collections, each holding points (a vector or set of named vectors, an id, and a JSON payload for metadata), with payload fields optionally indexed (keyword, integer, float, geo, text) to support fast filtered search.

Practical Details

For multi-tenant use cases, Qdrant's documented approach is a payload-based tenant field (with a keyword index on it) within one collection rather than a separate collection per tenant, since collection-per-tenant doesn't scale well once tenant count grows into the hundreds or thousands. Access control is enforced at the API-key level rather than per-point or per-payload-field, so data isolation between tenants has to be built into query logic (via the payload filter), not assumed from the platform.

Actionable Considerations

1. Use a payload-based tenant field with an index, not one collection per tenant, when building a multi-tenant application on Qdrant.
2. Enforce tenant isolation explicitly in every query's payload filter, since Qdrant's access control doesn't isolate data per tenant automatically.
3. Index only the payload fields you actually filter on, since indexing every field adds overhead without a corresponding benefit.

Qdrant itself is the vector search engine underneath an AI application, not a model provider -- it stores embeddings your own model (OpenAI, Cohere, open-source sentence transformers, etc.) generates and returns nearest neighbors by cosine, dot product, or Euclidean distance, whichever the collection is configured for.

Practical Details

Named vectors let a single point carry multiple vector representations (for example a text embedding and an image embedding), which matters for multi-modal retrieval or A/B testing two embedding models within the same collection. The Recommendation API extends plain similarity search by accepting positive and negative example points, useful for recommendation-style retrieval beyond a single query vector.

Actionable Considerations

1. Match your collection's distance metric to the one your embedding model was trained/normalized for, since cosine and dot product behave differently on unnormalized vectors.
2. Use named vectors if you need to store and query multiple embedding representations per point rather than creating separate collections.
3. Reindex or migrate embeddings deliberately when you swap embedding models, since vectors from different models aren't comparable in the same space.

Qdrant is open source (Apache 2.0) and can be self-hosted for free via Docker or Kubernetes, with Qdrant Cloud as the managed alternative billed on cluster size (RAM/CPU/storage) rather than per-query or per-vector, which changes the cost calculus compared to some competitors' per-operation pricing.

Practical Details

The real cost driver is memory: vectors and (unless quantized or moved to disk) the HNSW index live in RAM, so total dataset size and embedding dimensionality drive cluster sizing more directly than query volume. Self-hosting trades lower direct cost for the operational work of managing upgrades, backups (via snapshots), and scaling yourself, which is worth weighing honestly against a small team's actual bandwidth.

Actionable Considerations

• Estimate memory needs from vector count times dimensionality times bytes-per-value before sizing a cluster, since RAM is the primary cost driver.
• Evaluate quantization or on-disk storage early if your embeddings are high-dimensional and memory cost is a concern.
• Weigh Qdrant Cloud's managed pricing against the real operational cost of self-hosting (upgrades, backups, scaling), not just the sticker price difference.
• Confirm which distance metric and vector dimensionality your embedding model requires before finalizing collection design, since changing it later means re-embedding.
• Use collection-level snapshots as your backup strategy regardless of hosting choice, since they're the primary recovery mechanism Qdrant provides.

The concrete signal that Qdrant is working well is retrieval quality on your actual queries -- measured via recall against a ground-truth set or downstream metrics like click-through on returned results -- not just raw query latency.

Practical Details

Because HNSW is an approximate nearest-neighbor index, there's a real recall/latency tradeoff: a higher ef value returns more accurate results at the cost of slower queries, so the right setting depends on your specific accuracy bar. Payload filtering combined with vector search (Qdrant's filtered search) can change effective recall too, since a restrictive filter narrows the candidate pool the HNSW graph searches.

Actionable Considerations

1. Measure recall against a labeled or ground-truth query set rather than relying on latency alone as your quality signal.
2. Adjust the ef search parameter deliberately once you know your accuracy requirements, rather than leaving it at the default.
3. Test filtered search performance specifically if your queries combine payload filters with vector similarity, since filter selectivity affects both speed and recall.

Qdrant exposes both REST and gRPC APIs, with official client libraries for Python, JavaScript/TypeScript, Go, Rust, and Java/.NET, which is the practical integration surface most applications use rather than calling the raw API directly.

Practical Details

Qdrant integrates commonly through RAG (retrieval-augmented generation) frameworks like LangChain and LlamaIndex, which ship Qdrant vector-store connectors, as well as directly from application backends via the client SDKs. Batch upsert operations (inserting many points in one call) are meaningfully faster than inserting points one at a time, which matters for any pipeline doing bulk embedding ingestion.

Actionable Considerations

• Use the gRPC client over REST for latency-sensitive, high-throughput workloads, since gRPC has lower per-request overhead.
• Batch point upserts rather than inserting one at a time when loading or refreshing large embedding sets.
• Use an existing LangChain or LlamaIndex Qdrant connector if you're already building on one of those frameworks, rather than writing raw client calls.
• Use collection aliases when automating reindexing pipelines, so you can swap a new collection in without changing the application's connection string.

Qdrant's own documentation and GitHub issues/Discord community are the primary self-serve support channels for the open-source product; Qdrant Cloud customers additionally get managed-service support tied to their plan.

Practical Details

The most common real-world issues are dimension mismatches (upserting a vector whose length doesn't match the collection's configured size, which fails outright), unindexed payload fields causing slow filtered queries, and memory pressure on self-hosted instances sized without accounting for HNSW index overhead alongside the raw vectors. Qdrant's collection info and cluster telemetry endpoints are the first place to check when diagnosing unexpected latency or memory behavior.

Actionable Considerations

• Check collection info and cluster telemetry endpoints first when diagnosing unexpected latency, before assuming it's a code-level issue.
• Verify payload fields used in filters are actually indexed if filtered queries are slower than expected.
• Account for HNSW index memory overhead, not just raw vector size, when sizing a self-hosted instance to avoid memory pressure.