For most web applications, PostgreSQL with the pgvector extension is sufficient for storing and querying up to 10 million vector embeddings, primarily due to the HNSW indexing introduced in version 0.6.0. Dedicated vector databases like Pinecone or Qdrant are only strictly necessary when an application exceeds 50 million embeddings, requires sub-20 millisecond query latency at high concurrency, or relies on distributed, GPU-accelerated infrastructure.

Adding retrieval-augmented generation to a web application forces an architectural fork. You must store high-dimensional embeddings somewhere. The default reflex for many engineering teams is spinning up a managed vector database immediately. Adding a new data store fractures the architecture. It breaks transactional guarantees. You now have to synchronize relational data with vector payloads across a network boundary. That operational tax is high. Measuring whether you actually need a specialist engine requires looking at index mechanics, memory scaling, and data synchronization overhead.

The Baseline: PostgreSQL and pgvector

PostgreSQL handles vectors as a custom data type via the pgvector extension. Early versions struggled with performance because they relied on IVFFlat (Inverted File Flat) indices. IVFFlat required the data to be loaded before the index was built, forcing developers to recalculate centroids whenever the dataset drifted. This created severe operational bottlenecks for applications with frequent write operations.

The release of pgvector v0.6.0 changed the baseline. It introduced Hierarchical Navigable Small World (HNSW) indexing. HNSW builds a multi-layered graph that allows fast approximate nearest neighbor search without requiring a pre-training step. It dynamically updates as new vectors are inserted. For standard 1536-dimensional vectors produced by OpenAI’s text-embedding-3-small model, pgvector can now execute sub-50ms queries over millions of records.

Postgres does impose physical constraints. Standard Postgres pages are hardcoded to 8KB. High-dimensional vectors can exceed this, forcing Postgres to compress them or move them out of line using TOAST (The Oversized-Attribute Storage Technique). TOAST lookups incur disk I/O penalties. While newer Postgres versions optimize this slightly, keeping index structures in RAM is mandatory for acceptable performance. If your HNSW index size exceeds available memory, the database falls back to disk, and query latency spikes exponentially.

The Specialists: Dedicated Vector Engines

Dedicated vector databases like Pinecone, Milvus, and Qdrant strip away relational overhead to maximize similarity search throughput. They implement advanced memory management techniques specifically designed for high-dimensional arrays. Qdrant, written in Rust, leverages memory-mapped files (mmap). This keeps its idle memory usage incredibly low—often under 50MB for small clusters—and allows the operating system to page data out to disk predictably without hard out-of-memory crashes.

Serverless architectures have reshaped the cost modeling for these specialists. Pinecone Serverless charges directly based on usage, pricing operations at roughly $0.33 per 1 million read units and $2.00 per 1 million write units. For bursty AI workloads or enterprise AI integration tools that process heavy batch embeddings overnight but remain idle during the day, this decoupled compute-and-storage model is vastly cheaper than running a permanently over-provisioned Postgres RDS instance.

Scale dictates infrastructure. Milvus version 2.4 introduced NVIDIA GPU acceleration for index building and querying. If your architecture processes billion-scale datasets, running multi-vector queries against a distributed Milvus cluster will outperform pgvector entirely. Dedicated engines also native support for sparse-dense hybrid search (like BM25 combined with dense embeddings), which pgvector currently requires complex custom queries to replicate.

Infrastructure Complexity and the Synchronization Tax

Splitting your data across two stores creates immediate consistency problems. When a user deletes their account in Postgres, the corresponding embeddings must be scrubbed from the vector database to maintain compliance. Doing this reliably requires an outbox pattern, asynchronous workers, and robust retry logic. A dual-store architecture guarantees that at some point, the systems will drift out of sync.

Relying on a single Postgres instance guarantees Atomicity, Consistency, Isolation, and Durability (ACID). You can insert the user record and the embedding in a single transaction. If the embedding fails, the user record rolls back. You avoid building a distributed tracing pipeline just to ensure data actually made it to the vector index.

Introducing a second database also complicates your caching strategy. When querying across two stores, you cannot easily invalidate Valkey or Redis caching layers based on a single trigger. The operational burden of managing migrations, backups, and network policies doubles.

Cost and Performance Comparison

Evaluating these solutions requires mapping them against specific engineering constraints. Latency, memory limits, and maintenance overhead define the boundary of where pgvector stops making sense.

Cost modeling is highly variable. A self-hosted Postgres instance costs a fixed amount monthly regardless of read/write volume. Serverless vector databases scale to zero, but punish high-throughput continuous writes. If you stream real-time embeddings directly to the client using Server-Sent Events (SSE), the constant read/write cycles against a managed vector database can quickly exceed the cost of a dedicated Postgres server.

Common Failure Modes in Vector Search

Over-indexing is the most frequent architectural mistake. Developers default to indexing every field. HNSW indices are computationally expensive to build and consume massive amounts of memory. Indexing billions of vectors with high connectivity parameters (M and ef_construction) will choke Postgres, blocking subsequent write operations while the graph rebuilds.

Another failure mode is ignoring hybrid search realities. Pure semantic search often returns irrelevant results when users search for exact product SKUs or specific names. Developers quickly realize they need relational filtering (e.g., “find vectors similar to X where tenant_id = Y”). Postgres handles pre-filtering via native WHERE clauses effortlessly. Dedicated vector databases implement metadata filtering, but applying complex relational joins across an external API boundary results in severe network latency.

Finally, teams underestimate the memory footprint of the vectors themselves. Storing 1 million 1536-dimensional vectors requires roughly 6GB of RAM just for the raw data, ignoring index overhead. Provisioning a database instance without accounting for the multi-gigabyte memory requirement of the HNSW graph guarantees constant cache evictions and disk thrashing.

Verdict: When to Split the Stack

If your application has fewer than 10 million vector embeddings and your team already maintains Postgres, installing pgvector is the correct engineering decision. The performance is completely adequate, and the operational simplicity of ACID compliance far outweighs the marginal latency improvements of a dedicated store.

Move to a dedicated vector database only when Postgres metrics prove it is failing. If your HNSW indices are forcing expensive RAM upgrades on your primary database, or if you require specialized features like multi-vector search and disk-ann hybrid architectures, migrate to Qdrant or Pinecone. Do not pay the dual-database synchronization tax until your scale forces the issue.

Evaluate your architecture strictly by the numbers. Run the load test against pgvector on your existing database instance before engaging a third-party vendor. Add the specialist tool only when query latency exceeds your application’s defined thresholds or memory costs outpace the pricing of managed vector services.