Qdrant vs pgvector at 10M+ Vectors: What Actually Changes at Scale

You put your vector embeddings in Postgres because it was easy. It worked perfectly for the pilot, keeping your relational data and semantic representations in one place. Now your enterprise RAG system has processed 10 million document chunks, your database requires a 128GB RAM instance just to keep the search index in memory, and your core application is experiencing latency spikes because the AI feature is monopolizing database compute.

This is how AI technical debt accumulates, translating directly into escalating cloud bills and sluggish user experiences. Across the industry, most enterprise AI projects stall in pilot purgatory because teams push prototype architectures into production environments. Running a massive vector workload on your primary transactional database is a classic example of AI spaghetti: it functions in a demo, but risks crashing your core application under real-world concurrent load.

Choosing between pgvector and a dedicated vector engine like Qdrant is not a matter of which tool is "better." It is a business decision governed by memory physics, hardware costs, and the architectural limits of relational databases. Here is exactly what changes when you cross the 10-million vector threshold, and how to protect both your product's performance and your operational margins.

The Memory Physics of 10 Million Vectors

For business leaders and engineering managers, "memory physics" isn't just an abstract technical constraint—it is the primary driver of your monthly cloud infrastructure spend. Understanding how vector data scales allows you to forecast your margins accurately and avoid emergency database migrations when user adoption spikes. If your hardware cannot keep pace with these physics, your users will experience severe application lag, leading to immediate customer churn.

Vectors are arrays of floating-point numbers. If you use a standard embedding model like OpenAI's text-embedding-3-large or an open-weight equivalent like multilingual-e5-large, you are typically dealing with 1,536 to 3,072 dimensions per vector. (While we have detailed how to optimize production RAG on limited hardware, scaling to tens of millions of vectors demands a dedicated architecture).

Let us calculate the raw storage required for 10 million vectors at 1,536 dimensions, using standard 32-bit floats (float32):

• ▸Formula: Number of Vectors × Dimensions × Bytes per Float
• ▸Math: 10,000,000 × 1,536 × 4 bytes = 61,440,000,000 bytes (roughly 61.4 GB)

But raw storage is only the beginning. To perform fast similarity searches, you cannot scan 61.4 GB of data sequentially. You must build an index, almost universally using the Hierarchical Navigable Small World (HNSW) algorithm.

An HNSW index maintains a multi-layered graph of connections between vectors. Depending on your configuration parameters (specifically the number of bi-directional links, m), the HNSW index overhead typically adds 30% to 50% to your raw data size.

Therefore, 10 million vectors require approximately 90 GB of memory.

For vector search to return results quickly, that entire 90 GB index needs to reside in RAM. If it drops to disk, your system must execute random disk reads to traverse the HNSW graph. Even on modern NVMe SSDs, disk swapping during an HNSW traversal will cause query latency to spike from ~50 milliseconds to hundreds of milliseconds or worse. The user experience of your RAG application severely degrades, risking your SLA commitments and key customer accounts.

pgvector: The Default That Costs More at Scale

pgvector is an exceptional extension. If you have fewer than one million vectors, pgvector is the correct choice. Introducing a separate database infrastructure for a small dataset adds network hops and maintenance overhead with no tangible business benefit.

However, PostgreSQL is fundamentally a row-based relational database designed for transactional integrity (ACID compliance), not high-dimensional array mathematics. When you scale pgvector to 10 million vectors or beyond, you hit three structural walls that directly impact your bottom line.

1. The Cost of Vertical Scaling PostgreSQL relies heavily on its shared_buffers and the operating system's page cache to keep frequently accessed data in memory. To keep your 90 GB vector index in RAM, you must scale your Postgres instance.

If you are using a managed service like AWS RDS, you cannot add just RAM. You must upgrade the entire instance class. Moving to an db.r6g.4xlarge instance (128 GB RAM, 16 vCPUs) to accommodate your vector index costs approximately $1,300 per month (illustrative Single-AZ pricing). You are paying for enterprise-grade CPU and IOPS capacity that you do not need, simply because vector indexes are memory hogs. This is highly inefficient capital allocation.

2. Compute Contention and Business Continuity Risk Vector similarity search is highly CPU-intensive. When a user queries your RAG system, pgvector computes the distance (e.g., cosine similarity) between the query vector and thousands of candidate vectors in the graph. If your AI application experiences a surge in concurrent users, these distance calculations will consume available CPU cycles.

If this is the same PostgreSQL instance that runs your core business application, your standard transactional queries (INSERT, UPDATE) will queue behind the vector searches. Your AI feature risks dragging down the performance of your entire product, potentially halting checkouts, user sign-ups, or critical business workflows.

3. Inefficient Payload Filtering Production-grade enterprise RAG is rarely just semantic search. Users apply filters: "Find contracts matching this clause, but only those signed in 2025, in the EMEA region, with a value over $100,000."

In Postgres, combining vector similarity with complex SQL WHERE clauses forces the query planner into a difficult choice. Even with recent improvements to pgvector's index scans, highly restrictive filters force the planner to traverse a much larger portion of the graph to find enough valid matches, leading to unpredictable latency.

Qdrant: The Purpose-Built Engine for Production

For enterprise buyers, migrating to a dedicated vector engine is an exercise in structural cost avoidance. By decoupling intensive analytical search workloads from your primary database, you protect your core business operations while slashing your ongoing infrastructure run rate.

When an enterprise AI system outgrows a relational database, Verel migrates the search workload to a purpose-built vector engine. We standardise on Qdrant for production deployments because it is written in Rust (avoiding the garbage collection pauses of JVM-based databases) and handles memory management specifically for high-dimensional data.

Migrating to Qdrant solves the scaling problem through three specific mechanisms that directly reduce infrastructure costs and operational risks.

1. Scalar and Product Quantization Qdrant natively supports aggressive quantization—compressing your vectors to save RAM with minimal loss in retrieval accuracy. By converting 32-bit floats to 8-bit integers (int8 scalar quantization), you reduce the memory footprint by a factor of four.

• ▸Math with int8 Quantization: 10,000,000 × 1,536 × 1 byte = 15.3 GB

Qdrant keeps the compressed 15.3 GB vectors in RAM for the initial HNSW graph traversal, and only pulls the full-precision 32-bit vectors from disk for the final re-scoring phase. This means you can serve 10 million vectors from a machine with 24 GB of RAM instead of 128 GB, significantly reducing hardware costs without compromising search precision.

2. Memory-Mapped Storage (mmap) Unlike Postgres, which pulls data into shared_buffers, Qdrant uses memory-mapped files. It allows the Linux kernel to manage paging vector data directly from disk to RAM. If your system experiences memory pressure, Qdrant gracefully degrades by reading from disk rather than crashing or locking up the database. This makes your application highly resilient under unexpected spikes in concurrent traffic.

3. Native Payload Filtering Qdrant was designed from day one to handle metadata. It stores your metadata (payloads) alongside the vectors and uses a custom query planner that seamlessly integrates payload filtering into the HNSW graph traversal itself (single-stage filtering). Whether your filter eliminates 10% or 99% of the dataset, Qdrant helps maintain predictable, sub-second latency because it evaluates the filter conditions dynamically as it navigates the graph.

If you are planning your migration or building a high-scale RAG architecture from scratch, our team can deploy and optimize this infrastructure for you, ensuring your system remains fast and cost-effective.

Cost and Architecture Comparison at 10 Million Vectors

To make this concrete, here is the architectural and cost comparison for an enterprise system managing 10 million document chunks (1,536 dimensions) with moderate concurrent traffic.

Note: Costs are illustrative based on standard 2026 public cloud pricing for managed services.

Beyond the monthly cloud bill, consider the engineering opportunity cost. Keeping pgvector alive at 10M+ vectors often requires weeks of senior developer time spent on indexing tweaks, query optimization, and database tuning—time stolen from your core product roadmap. Migrating to an isolated vector database permanently offloads this maintenance burden.

The Migration Path: When to Move and How

Do not migrate prematurely. Adding a distributed system to your architecture increases operational complexity. You have to manage data synchronisation, handle network failures between your primary database and the vector store, and secure another endpoint.

Here is our decision framework for moving from prototype to production:

• ▸Under 1 Million Vectors: Stay on pgvector. The compute and memory overhead is negligible. The simplicity of a single database outweighs the efficiency gains of a dedicated engine.
• ▸1 Million to 5 Million Vectors: Implement half-precision vectors (float16) in pgvector. This cuts your memory footprint in half without requiring new infrastructure. Monitor your shared_buffers eviction rates and query response times closely.
• ▸Over 10 Million Vectors (or heavy payload filtering): Migrate to Qdrant.

How the Migration Works You do not need to regenerate your embeddings, which could cost thousands of dollars in LLM API fees depending on your chunk size. A properly planned migration carries zero downtime risk for your existing users and follows a standard Extract, Transform, Load (ETL) process:

1. ▸Extract: Read the existing embeddings and metadata from PostgreSQL.
2. ▸Transform: Format the data into Qdrant's JSON payload structure.
3. ▸Load: Batch upload the vectors to Qdrant using their gRPC API for maximum throughput.

Once migrated, your architecture shifts. PostgreSQL remains your source of truth for business data. When a new document is uploaded, your backend inserts the text into Postgres, generates the embedding, and uses the Transactional Outbox pattern to asynchronously sync the vector to Qdrant. Your core application remains fast, your primary database is protected from heavy vector math, and your RAG pipeline scales independently.

Frequently Asked Questions

Q: What is the typical ROI and payback period of migrating to Qdrant? For an enterprise managing 10 million vectors, migrating from AWS RDS pgvector (scaling up to memory-optimized instances) to a dedicated Qdrant cluster yields an average infrastructure cost saving of $1,050/month. Given a typical 2-to-3-week migration effort, most engineering teams achieve full payback on the transition within 3 to 4 months, while permanently eliminating the risk of AI-induced database outages.

Q: Does pgvector support quantization to save memory? Yes, recent versions of pgvector support half-precision (float16) and binary vectors. However, while this reduces the physical size of the index, it does not solve the fundamental issue of compute contention. Vector search remains a CPU-heavy analytical workload running inside your transactional database, risking the stability of your core business data.

Q: Will migrating to Qdrant introduce network latency? Technically, yes. Querying Qdrant adds a network hop (typically 2–5 milliseconds if deployed in the same VPC) compared to querying Postgres locally. However, this minor network penalty is vastly outweighed by avoiding the massive latency spikes (often 200ms+) that occur when Postgres is forced to swap a massive HNSW index to disk under load.

Q: Can we run Qdrant on-premise for data sovereignty? Yes. For our clients in the Gulf region operating under strict data localization laws (such as PDPL compliance in Saudi Arabia or UAE data regulations), we deploy Qdrant as Docker containers on local infrastructure. Because it is written in Rust and highly resource-efficient, it runs comfortably on standard enterprise servers without requiring specialized GPU hardware for the retrieval phase, keeping your hosting costs predictable.

Q: Are there other dedicated vector databases besides Qdrant? Yes, Milvus, Weaviate, and Pinecone are all mature options. Pinecone is excellent for teams that want zero operational overhead (serverless), but it cannot be deployed on-premise. Milvus scales to billions of vectors but has a heavier architectural footprint. We default to Qdrant for the mid-market and enterprise because it strikes the best balance of single-node performance, Rust-based memory safety, and flexible deployment models.

Moving an enterprise AI system from a pilot to production requires aligning your infrastructure with the physics of your data. If your RAG pipeline is growing, plan your migration before your database runs out of memory and impacts your customers.