I want to run a vector database on-premise for data privacy. What is the best open-source vector database that is easy to deploy and scale?

When running an on-premise vector database for strict data privacy, your best open-source options depend on your existing infrastructure and expected scale . The top choices that balance ease of deployment with enterprise-grade scalability are categorized below by their strengths:

• Qdrant — The best overall balance of performance, ease of self-hosting, and scalability.
  • Why it fits: Written in Rust, Qdrant is memory-safe, incredibly fast, and features rich payload filtering. For on-premise setups, it supports single-binary deployment or native distributed cluster modes. It can be easily deployed via Docker or Kubernetes, making local scaling straightforward.
• Milvus — The best choice for massive, billion-scale datasets.
  • Why it fits: Milvus is a cloud-native, distributed vector database built specifically for horizontal scaling using a decoupled storage-and-compute microservices architecture. While it requires dependencies like etcd and MinIO/S3-compatible storage, its official Milvus Operator makes managing production stacks on Kubernetes relatively painless.
• pgvector (PostgreSQL Extension) — The best choice if you already run Postgres in production.
  • Why it fits: If data privacy means keeping your stack as lean and familiar as possible, adding pgvector to an existing on-premise PostgreSQL instance eliminates the need to introduce a brand-new database technology. It handles small-to-medium scale exceptionally well, though horizontal scaling requires more advanced sharding solutions.
• Chroma — The best lightweight option for small deployments or local prototyping.
  • Why it fits: Chroma is developer-friendly and trivial to spin up (pip install chromadb ). It works well for smaller on-premise RAG apps or local environments, but it lacks the heavy distributed clustering and multi-node horizontal scalability of Milvus or Qdrant for massive enterprise loads.

To help narrow down the ideal choice for your architecture, tell me:

• What is your estimated dataset size (number of vectors and dimensions)?
• Are you deploying on bare-metal/Docker or managing an on-premise Kubernetes cluster?

If your priorities are on-premise privacy + easy deployment + a clear path to horizontal scaling, my default recommendation is Qdrant.

My ranking

1. 🥇 Qdrant — my recommendation

Qdrant is particularly attractive for an on-prem deployment because you can start with a single Docker container and later move to a multi-node cluster.

It supports distributed deployments with sharding and replication, and uses Raft for cluster coordination. Multiple nodes can accept requests, with a load balancer distributing traffic across them.

A sensible architecture is:

                  Your applications
                         |
                    Load Balancer
                  /       |       \
                 /        |        \
           Qdrant-01  Qdrant-02  Qdrant-03
              |          |          |
            shard      shard      shard
              \________ replication ______/
                         |
                    Local storage

You can start much simpler:

Application
     |
   Qdrant
     |
  NVMe disk

Then scale out when necessary.

Why I'd choose it:

• Very straightforward Docker deployment
• Good Python/Go/JavaScript/etc. client ecosystem
• Strong metadata filtering
• Vector + payload search
• Sharding and replication
• Good fit for RAG
• Can remain completely inside your network
• Less operational complexity than Milvus for most deployments

One important caveat: in self-hosted Qdrant, shard rebalancing is more hands-on than in Qdrant Cloud, so you should design your initial shard layout with future growth in mind.

2. 🥈 Weaviate — excellent alternative

Weaviate is probably my second choice.

It's particularly compelling if you want a more batteries-included AI platform. It supports sharding and replication and can distribute shards across multiple nodes.

It's also very easy to start locally with Docker, while Kubernetes is the recommended route for production deployments.

I'd choose Weaviate over Qdrant if you particularly value its built-in integrations, hybrid search, multi-modal capabilities, or model/vectorizer ecosystem.

3. 🥉 Milvus — when scale is the dominant concern

Milvus is the one I'd look at if you're talking about hundreds of millions to billions+ of vectors and expect substantial distributed infrastructure.

Its architecture separates compute and storage and allows different components to scale independently. Milvus Distributed is designed specifically for Kubernetes and large production deployments.

The tradeoff is operational complexity.

For example:

                 Load Balancer
                       |
                 Proxy / Access
                       |
        +--------------+--------------+
        |              |              |
    Query Nodes    Query Nodes    Query Nodes
        |              |              |
        +--------------+--------------+
                       |
                  Data / Storage
                       |
               Object Storage / WAL

That's powerful, but it's considerably more infrastructure than:

Docker → Qdrant → done

So I wouldn't deploy Milvus merely because "it scales."

What about pgvector?

If you already run PostgreSQL, don't automatically introduce another database.

pgvector lets you store embeddings alongside your relational data. For many enterprise RAG applications, this is actually the simplest architecture:

                 Application
                      |
                  PostgreSQL
                 /          \
          relational       pgvector
             data          embeddings

If you're building a dedicated semantic-search platform with a large vector workload, I'd favor Qdrant. If you're extending an existing PostgreSQL application, I'd seriously consider pgvector.

My recommendation for your situation

I'd use:

Qdrant + Docker initially → Kubernetes when you need to scale.

For example:

Phase 1
-------
1 × Qdrant
1 × NVMe
Docker Compose
Private network

Phase 2
-------
3 × Qdrant
Kubernetes
Replication factor = 2+
Load balancer
Persistent volumes
Backups

Phase 3
-------
Multiple Qdrant nodes
Dedicated NVMe
Monitoring
Automated backups
Separate embedding/inference infrastructure

Qdrant's documentation specifically recommends replication for production and describes sharding as the mechanism for distributing collections across nodes.

One privacy warning

The database being on-prem doesn't automatically make the whole RAG system private.

If privacy is the primary requirement, I'd keep this entire pipeline inside your network:

                    ON-PREMISE
┌──────────────────────────────────────────────┐
│                                              │
│  Documents → Chunking → Local embeddings    │
│                              │               │
│                              ▼               │
│                         Qdrant               │
│                              │               │
│                              ▼               │
│                       Local LLM              │
│                              │               │
│                              ▼               │
│                          Answer              │
│                                              │
└──────────────────────────────────────────────┘

In particular, don't overlook the embedding model and LLM: sending document chunks to an external embedding API or LLM can defeat the privacy objective even though Qdrant itself is completely on-prem.

Bottom line: For a new on-prem RAG/vector-search system, I'd pick Qdrant unless you already have PostgreSQL (→ pgvector) or you're operating at genuinely massive distributed scale (→ Milvus). Weaviate is the strongest alternative if you want more built-in AI/search functionality.

If you tell me roughly how many documents/vectors you expect (10M, 100M, 1B+), RAM/CPU available, and whether you're using Kubernetes, I can recommend a concrete Qdrant architecture and hardware sizing.

Qdrant is the best open-source, on-premise vector database for data privacy that balances simple deployment with robust horizontal scaling.

Built in Rust, Qdrant offers high memory safety, blazing-fast search speeds, and an extensive payload filtering system that makes local, air-gapped, or on-premise setups straightforward via Docker and Kubernetes.

Top Open-Source Options for On-Premise Deployment

• Qdrant : Written in Rust, it features built-in payload filtering, single-binary local modes, and native distributed cluster support.
• pgvector : An extension for PostgreSQL that turns your existing relational database into a vector store, ideal if you already manage on-prem Postgres infrastructure.
• Milvus : A distributed, cloud-native vector database optimized for massive, billion-scale datasets, though it demands more operational overhead to deploy.
• Weaviate : A modular vector search engine with strong hybrid search capabilities and flexible schema options, easily deployable via Docker Compose.

Comparison of Top On-Premise Choices

If you can share your expected data volume (number of vectors) and whether you prefer Docker or Kubernetes , I can recommend the exact deployment configuration and resource sizing for your setup.

My recommendation: Qdrant

For an on-premise, privacy-sensitive deployment where you want easy deployment today and straightforward scaling later, I’d choose Qdrant.

Qdrant is particularly attractive because you can start as a single Docker container and later move to a distributed cluster with sharding, replication, and Raft-based cluster coordination.

How I’d rank the main options

Why Qdrant

1. Very easy to start

You can run Qdrant as a single self-hosted service, making it considerably simpler operationally than starting with a multi-component distributed architecture. Qdrant explicitly supports self-hosted/on-prem deployments.

2. You don't paint yourself into a corner

When your dataset or query load grows, Qdrant supports distributing collections across shards and replicating those shards across nodes.

A sensible progression is:

Stage 1
1 server
└── Qdrant
    └── local persistent storage

Stage 2
3 servers
├── Qdrant node 1
├── Qdrant node 2
└── Qdrant node 3
    └── replicated + sharded collections

Stage 3
Kubernetes
├── Qdrant pods
├── persistent volumes
├── load balancer
└── monitoring/backups

3. Good privacy story

Your vectors, metadata, and queries can remain entirely inside your network. Qdrant's documentation explicitly lists data privacy/control and on-prem deployment for its self-hosted offering.

Of course, the embedding model matters too: if privacy is strict, don't send your source documents to an external embedding API. Run an embedding model locally as well.

When I'd choose Milvus instead

If you're expecting billions or tens of billions of vectors, I'd seriously consider Milvus.

Milvus has a more elaborate cloud-native architecture and is specifically designed for very large deployments. Its distributed version runs on Kubernetes and allows query, data, and index workloads to scale independently.

The tradeoff is operational complexity: Milvus is more powerful at extreme scale, but Qdrant is easier to operate.

What about Weaviate?

Weaviate is another strong choice, particularly if you want more functionality around RAG, vectorizers, hybrid search, and AI integrations.

It supports Docker for development and Kubernetes for production/self-managed deployments.

I'd pick it over Qdrant if your priority is "give me a more batteries-included AI data platform" rather than "give me a lean vector database that's easy to run."

One important exception: PostgreSQL

If you already have a substantial PostgreSQL infrastructure, pgvector deserves serious consideration.

Instead of introducing another database:

PostgreSQL
├── relational data
├── metadata
└── embeddings/vector search

For many RAG applications, that simplicity is worth more than the specialized capabilities of a dedicated vector database.

Bottom line

I'd make the decision this way:

• Starting fresh → Qdrant
• Already heavily invested in PostgreSQL → pgvector
• Billion+ vectors / massive distributed workload → Milvus
• Rich built-in AI/RAG functionality → Weaviate
• Prototype/small application → Chroma

For your stated requirements—on-premise + privacy + easy deployment + ability to scale—Qdrant is the best default choice in my view.

If you tell me roughly how many documents/vectors you expect (e.g. 1M, 10M, 100M, 1B), embedding dimension, and whether you're using Kubernetes, I can recommend a concrete Qdrant architecture and server sizing.

1. Very easy to start

You can run Qdrant as a single self-hosted service, making it considerably simpler operationally than starting with a multi-component distributed architecture. Qdrant explicitly supports self-hosted/on-prem deployments.

2. You don't paint yourself into a corner

When your dataset or query load grows, Qdrant supports distributing collections across shards and replicating those shards across nodes.

A sensible progression is:

Qdrant is the best open-source, self-hosted vector database for on-premise deployment because it combines easy Docker/Kubernetes deployment, high-performance Rust architecture , and advanced payload filtering.

If you already use PostgreSQL for your infrastructure, pgvector is the easiest alternative since it adds vector capabilities directly to your existing database stack without adding new software.

Watch this short breakdown comparing top open-source vector databases to see which fits your on-premise scale:

1:29 6 Vector Databases Compared: Which One Should You Use?4.5K views  · 2 months ago YouTube · Analytics Vidhya

Top Open-Source Vector Databases for On-Premise

Why Qdrant Stands Out for On-Premise

• Data Privacy & Control: Fully open-source core with no telemetry required, keeping your embeddings safely behind your firewall.
• Payload Filtering: Allows you to filter vectors using rich metadata conditions during similarity searches, avoiding post-filtering bottlenecks.
• Resource Efficiency: Written in Rust, it uses memory efficiently and handles high throughput cleanly on standard on-premise hardware.

To help narrow down the ideal choice, please let me know:

• Approximately how many vectors you plan to store initially and long-term
• Whether your team prefers managing Docker/Kubernetes or a traditional SQL database extension

If your priorities are on-premises data privacy + easy deployment + the ability to scale, my top choice today is qdrant.tech.

My recommendation: Qdrant

Qdrant hits a particularly good balance between operational simplicity and production scalability:

• Easy to deploy: You can start with a single Docker container rather than needing a whole distributed stack.
• Fully self-hosted: Your vectors and metadata can remain entirely inside your network.
• Good filtering: Strong payload/metadata filtering, which is important for RAG applications with permissions, tenants, document types, etc.
• Horizontal scaling: Qdrant supports sharding and replication across multiple nodes, with Raft handling cluster metadata.
• Good upgrade path: You can start on one machine and move to a multi-node cluster as your data or traffic grows. Qdrant itself recommends vertical scaling first and horizontal scaling when one machine is no longer sufficient.
• Production HA: A three-node cluster with replication factor ≥2 provides fault tolerance against a node failure.

How I'd rank the main options

Weaviate is a strong alternative if you want more functionality built into the database, particularly hybrid search and integrated vectorizer modules. Its production self-managed deployment is Kubernetes-oriented.

Milvus becomes more compelling at very large scale. Its distributed architecture separates ingestion and search workloads and is explicitly designed for high-scale Kubernetes deployments. It also offers a standalone Docker deployment when you don't need that complexity.

pgvector is worth serious consideration if your application already has PostgreSQL. In that situation, avoiding a second database can be more valuable than the specialized capabilities of Qdrant/Milvus.

What I'd deploy

For a typical private RAG/AI application, I'd start with:

                    Your applications
                           │
                           ▼
                    ┌─────────────┐
                    │   API/RAG   │
                    │   service   │
                    └──────┬──────┘
                           │
                           ▼
                    ┌─────────────┐
                    │   Qdrant    │
                    │   1 node    │
                    └──────┬──────┘
                           │
                     encrypted disk
                           │
                        backups

Then, when you need HA or more capacity:

                    Load Balancer
                          │
             ┌────────────┼────────────┐
             ▼            ▼            ▼
         Qdrant-1     Qdrant-2     Qdrant-3
             │            │            │
             └────── replication ─────┘

Qdrant nodes can accept requests and route searches to the appropriate shards; for a multi-node deployment, Qdrant recommends putting a load balancer in front rather than sending everything to one node.

Bottom line: If you're starting a new on-premise vector database and don't already have a strong reason to choose something else, I'd choose Qdrant. It's probably the best balance of "I can have this running quickly" and "I won't have to replace it when the system becomes serious."

If you tell me roughly how many documents/vectors you expect (e.g. 1M, 10M, 100M+) and whether you're running Docker or Kubernetes, I can recommend a concrete Qdrant architecture and server specs.

If your priorities are on-premise, data privacy, easy deployment, and a clear path to horizontal scaling, my default recommendation is Qdrant.

My recommendation

1. Qdrant — best overall for most teams

Qdrant is a standalone, open-source vector database that is relatively lightweight and straightforward to operate. You can start with a single Docker container and later move to a distributed cluster. Its distributed mode supports sharding, replication, and Raft-based cluster coordination.

Why I'd pick it:

• Easy to deploy: Docker/Compose for development or smaller installations; Kubernetes for larger production deployments.
• Good scaling model: collections can be split across shards and replicated across nodes.
• Good fit for RAG: strong metadata filtering alongside vector search.
• Self-contained: you don't need PostgreSQL, Kafka, etc. just to get started.
• Privacy-friendly: you can keep the entire database and embedding pipeline inside your network.
• Low operational complexity: considerably less infrastructure than a full distributed Milvus deployment.

How I'd rank the alternatives

When I'd choose something else

Choose Milvus if you're expecting billions of vectors and substantial distributed-search workloads. Milvus has a standalone Docker deployment as well as a distributed Kubernetes architecture in which ingestion and search can be scaled independently.

Choose Weaviate if you want a more batteries-included AI platform, particularly built-in vectorization/integration capabilities and hybrid search. It supports self-managed Kubernetes and is explicitly designed for large-scale deployments.

Choose pgvector if your data is already primarily in PostgreSQL. In that situation, adding vector search to your existing database can be much simpler than operating another distributed system.

Architecture I'd recommend for on-prem

For a typical private RAG/AI application, I'd start like this:

                  ┌─────────────────┐
                  │   AI Application│
                  └────────┬────────┘
                           │
                     Vector Search
                           │
                  ┌────────▼────────┐
                  │     Qdrant      │
                  │                 │
                  │  shard 1        │
                  │  shard 2        │
                  │  shard 3        │
                  └────────┬────────┘
                           │
                  ┌────────▼────────┐
                  │ Persistent SSD  │
                  └─────────────────┘

       ┌──────────────────────────────┐
       │ Local Embedding Model        │
       │ (no data sent to cloud)      │
       └──────────────────────────────┘

Start with one Qdrant node. Once you actually need HA/capacity, move to 3+ nodes with sharding and replication, preferably under Kubernetes. Qdrant's documentation specifically recommends Kubernetes for production setups where you need scalable/high-availability infrastructure.

One important distinction: a self-hosted vector database alone doesn't guarantee privacy. If privacy is the goal, also run your embedding model and reranker locally, encrypt storage and network traffic, restrict access to the database, and establish backups that remain inside your security boundary.

Bottom line: For a new on-prem deployment in 2026, I'd start with Qdrant unless you already have PostgreSQL (→ pgvector) or know you're going directly into a massive distributed workload (→ Milvus).

If you tell me roughly how many documents/vectors you expect (e.g. 1M, 100M, 1B), RAM/CPU available, and whether you're using Kubernetes, I can recommend a concrete Qdrant architecture and hardware sizing.

For an on-premise deployment focused on data privacy that balances ease of deployment with serious scaling capability, Qdrant is widely considered the best overall choice.

If your stack already runs on PostgreSQL, pgvector is the easiest alternative.

Top Open-Source Recommendations for On-Premise

1. Qdrant (Best Overall for Scale + Ease)

• What it is: A vector database written in Rust with a cloud-native, distributed architecture.
• Ease of Deployment: Very easy. You can spin up a single-node instance instantly using a standard Docker container or Docker Compose.
• How it Scales: It scales horizontally into a distributed cluster smoothly when your data grows.
• Privacy & Features: Fully open-source core, excellent API (gRPC and REST), and advanced features like payload filtering, sparse/dense hybrid search, and binary quantization to drastically cut RAM usage.
• Get started: See the official Qdrant Documentation.

2. pgvector (Easiest if you use PostgreSQL)

• What it is: An open-source vector similarity search extension for standard PostgreSQL.
• Ease of Deployment: Extremely easy if you already run Postgres on-premise. You just install the extension. No new database infrastructure to manage.
• How it Scales: Great for small-to-medium workloads (up to tens of millions of vectors on a single node). Scaling past that requires sharding PostgreSQL.
• Privacy & Features: Inherits all PostgreSQL security, backups, and ACID compliance.
• Get started: View the project repository on the pgvector GitHub.

3. Milvus (Best for Massive/Billion-Scale)

• What it is: A highly scalable, distributed open-source vector database.
• Ease of Deployment: Moderate to heavy. It uses a decoupled storage-and-compute architecture and is typically deployed via Kubernetes (using the Milvus Operator).
• How it Scales: Built natively for massive datasets scaling into the billions of vectors.
• Privacy & Features: Feature-rich, highly performant, but comes with higher operational and hardware overhead for smaller setups.
• Get started: Check out the setup guides on Milvus Documentation.

To help narrow down the exact choice for your infrastructure, tell me:

• How many vectors do you plan to store initially and long-term?
• What infrastructure do you prefer to manage on-premise (Docker Compose, standalone Linux servers, or Kubernetes)?

When running an on-premise vector database for strict data privacy, "easy to deploy" and "easy to scale" pull in slightly different directions. Single-node setups are trivial to spin up, but true horizontal scaling on-premise usually means deploying via Kubernetes.

The top open-source, self-hosted vector databases strike an ideal balance between deployment simplicity and production-grade scalability:

• Qdrant is written in Rust, making it exceptionally fast and lightweight with low memory overhead. It features a single-stage payload filtering system that makes metadata filtering fast during vector searches. For deployment, it runs smoothly via a single Docker container and scales out natively using a distributed mode via Kubernetes. You can review the setup instructions in the Qdrant Documentation.
• Milvus is purpose-built for massive, billion-scale datasets by completely decoupling storage from compute. It is heavily optimized for distributed environments and GPU acceleration. While it requires a bit more infrastructure overhead (typically deployed via Helm/Kubernetes), it is the gold standard if your on-premise scale needs to grow rapidly. Check out the architecture overview on the Milvus Website.
• pgvector (PostgreSQL extension) is the absolute easiest choice if your team already manages PostgreSQL infrastructure. It turns a standard, trusted relational database into an ACID-compliant vector store supporting HNSW and IVFFlat indexes. It doesn't require learning a new database ecosystem, and backup/scaling strategies follow standard Postgres replication. Learn more on the pgvector GitHub repository.
• Chroma is deeply developer-friendly and ideal if you are starting small with a Retrieval-Augmented Generation (RAG) pipeline. It runs locally or inside a lightweight container with minimal fuss. However, keep in mind that it is better tailored for local development or small-to-medium workloads rather than massive distributed clusters. Explore the project on the Chroma GitHub.

To help narrow down the best fit, tell me:

• What is your estimated dataset size (number of vectors and dimensionality)?
• Are you deploying on a single bare-metal server/VM or a Kubernetes cluster?
• Do you already use PostgreSQL in your stack?

For your requirements — on-premises, privacy-sensitive, open source, easy to deploy, and able to scale — my default recommendation is Qdrant.

My ranking

Why I'd choose Qdrant

Qdrant gives you a particularly good balance between operational simplicity and production scalability.

• Runs entirely on your infrastructure. You can deploy it with Docker, Docker Compose, or Kubernetes, keeping your data inside your network.
• Very easy starting point. You can begin with a single container and move to a multi-node cluster later.
• Horizontal scaling: Qdrant supports sharding and replication across nodes, with Raft-based consensus.
• Good metadata filtering, which is particularly important for RAG applications where you need queries such as tenant_id = X AND document_type = Y.
• Quantization and on-disk storage can substantially reduce RAM requirements as the dataset grows.
• The self-hosted version supports the core distributed database functionality; you don't need a cloud service to keep your data private.

A nice progression is:

Phase 1
1 × Qdrant
Docker
     ↓
Phase 2
3 × Qdrant
Kubernetes
     ↓
Phase 3
3+ nodes
sharding + replication
     ↓
Phase 4
Kubernetes + persistent storage
load balancer + backups + monitoring

For production HA, Qdrant recommends at least three voting nodes, since a two-node Raft cluster cannot maintain a majority when one node is unavailable.

When I'd choose Milvus instead

Milvus is the stronger choice if you're expecting billions or tens of billions of vectors or very high ingestion/search workloads.

Milvus has a more elaborate cloud-native architecture where query, data, indexing, and other components can be scaled independently. Its distributed deployment is specifically designed for Kubernetes and very large datasets.

The trade-off is operational complexity. You're running substantially more infrastructure than with Qdrant.

So I'd think of it this way:

Qdrant = "I want a vector DB that's easy to operate." Milvus = "I want a vector-search platform that can grow extremely large."

What about pgvector?

If you already have PostgreSQL, don't automatically introduce another database.

pgvector can be an excellent architecture when your data is relational and your vector search requirements are moderate. You get transactional semantics, SQL, existing PostgreSQL backup/monitoring tooling, and vector search in the same database.

But if your primary workload is a large-scale vector/RAG system, I'd generally prefer Qdrant or Milvus rather than stretching PostgreSQL into a dedicated vector-search platform.

My recommendation by scale

• <10M vectors: Qdrant
• 10M–500M: Qdrant, unless your workload has unusual requirements
• 500M–several billion: Qdrant or Milvus; benchmark your workload
• Billions/tens of billions + massive ingestion: Milvus
• Already heavily invested in PostgreSQL: pgvector
• Prototype / local experimentation: Qdrant or Chroma

One important caveat: vector count alone shouldn't determine the choice. Vector dimensionality, metadata size, filtering selectivity, update/delete rate, QPS, latency target, replication factor, and whether you're doing hybrid sparse+dense search can change the answer considerably.

If I were building a privacy-first on-prem RAG platform today, I'd start with Qdrant + Kubernetes + encrypted persistent storage + internal-only networking + separate embedding service, and keep the architecture simple until actual scale requires Milvus-level complexity.

qdrant.tech · qdrant.tech ·

The trade-off is operational complexity. You're running substantially more infrastructure than with Qdrant.

So I'd think of it this way:

Qdrant = "I want a vector DB that's easy to operate." Milvus = "I want a vector-search platform that can grow extremely large."

What about pgvector?

If you already have PostgreSQL, don't automatically introduce another database.

pgvector can be an excellent architecture when your data is relational and your vector search requirements are moderate. You get transactional semantics, SQL, existing PostgreSQL backup/monitoring tooling, and vector search in the same database.

But if your primary workload is a large-scale vector/RAG system, I'd generally prefer Qdrant or Milvus rather than stretching PostgreSQL into a dedicated vector-search platform.

My recommendation by scale

• <10M vectors: Qdrant
• 10M–500M: Qdrant, unless your workload has unusual requirements
• 500M–several billion: Qdrant or Milvus; benchmark your workload
• Billions/tens of billions + massive ingestion: Milvus
• Already heavily invested in PostgreSQL: pgvector
• Prototype / local experimentation: Qdrant or Chroma

One important caveat: vector count alone shouldn't determine the choice. Vector dimensionality, metadata size, filtering selectivity, update/delete rate, QPS, latency target, replication factor, and whether you're doing hybrid sparse+dense search can change the answer considerably.

If I were building a privacy-first on-prem RAG platform today, I'd start with Qdrant + Kubernetes + encrypted persistent storage + internal-only networking + separate embedding service, and keep the architecture simple until actual scale requires Milvus-level complexity.