Dedicated vector database or a PostgreSQL extension: when Qdrant's sharding, filtering and quantization justify another service, and when pgvector inside an existing PostgreSQL estate is enough, with a verdict by corpus size and operations team.
Two Apache-2.0 vector databases with very different footprints: Qdrant's single Rust binary that scales by sharding against Milvus's disaggregated architecture on etcd, object storage and a write-ahead log, weighed by scale, operating effort and migration cost.
The usual vector store shortlist for retrieval-augmented generation: a PostgreSQL extension, a single-binary vector database and a disaggregated cluster compared on footprint, filtering, scaling model and operating effort, with a pick by corpus size and team.
Search speed and recall as data grows: pgvector HNSW and IVFFlat indexes with filtering applied after the index scan against Qdrant's payload filtering, quantization and sharding, and how to benchmark both before adding a separate service.
When a self-hosted Qdrant vector database should move from one node to a distributed cluster. Covers how cluster mode is enabled, Raft consensus, shard and replication factor planning, and the rebalancing and resharding that Qdrant Cloud automates but self-hosted clusters must handle by hand.
Qdrant Cloud against self-hosting the open-source engine: the free cluster, usage-billed Standard and minimum-spend Premium tiers, Hybrid and Private Cloud, managed features such as zero-downtime upgrades and automatic shard rebalancing, and the documented migration from OSS to Cloud.
Two purpose-built vector databases compared: Qdrant and Weaviate, whose core is BSD-3-Clause with some enterprise features behind a license key. Covers hybrid search, built-in vectorization, replication and consistency, RBAC and OIDC, multi-tenancy and the work to run each on Kubernetes.
A production vector database against Chroma's developer-first, Apache-2.0 embedded and client-server database. Explains when Chroma is enough, why its single-node and distributed modes differ, and what Qdrant adds for clustering, filtering and access control.
The three dedicated open-source vector databases on most RAG shortlists, compared on license and enterprise features, architecture and dependencies, scaling and replication, security controls and operating effort at different data sizes.
A vector database server against a similarity search library: what FAISS gives you (CPU and GPU indexes, compression) and what you must build around it (persistence, filtering, APIs, replication), against Qdrant's ready service, and when the library is the better choice.
A client-server vector database against an embedded retrieval library on the Lance columnar format: deployment model, filtering and hybrid search, multimodal data and versioning, scaling paths and the commercial cloud offerings behind each.
A dedicated vector database against adding dense_vector kNN search to an Elasticsearch cluster you may already run: index types and quantization defaults, hybrid keyword and vector search, licensing (Elastic License, SSPL or AGPL), resource needs and when one system beats two.