Do You Need a Vector Database in 2026? pgvector vs the Field

Do you need a vector database in 2026? For most products: no. Up to roughly ten million vectors, Postgres with the pgvector extension handles semantic search alongside your rows, joins and permissions — one database, no sync pipeline, no second system to operate. I run production vector search this way (pgvector + Voyage embeddings), and after a year of vendor shakeout — Pinecone reportedly exploring a sale, Qdrant raising $50M, Notion and Cursor moving to object-storage engines — the "boring Postgres" answer has aged better than most of the category. Here is the honest version of the decision, including exactly where Postgres stops being it.

The decision, by scale

• ≤ ~10M vectors — Postgres + pgvector. This is where most real products live. You keep transactional joins ("show results this user may see"), ACL filtering in the same query, and instant consistency between your data and its embeddings. Rule of thumb: about 1M 1536-dim vectors per 16 GB of RAM, and ~1,000 QPS per node is achievable with a tuned HNSW index.
• 10M–100M+ — tuning territory. Postgres still competes with help: Timescale's pgvectorscale (StreamingDiskANN + statistical binary quantization) benchmarked 50M vectors past Pinecone's old pod tier at a fraction of the cost. But budget real memory, index-build time and operational attention — or go dedicated (Qdrant, Milvus 2.6).
• Billions — a different sport. Cursor runs 1T+ vectors on turbopuffer; Notion left Pinecone for ~10× the scale at ~1/10 the cost. Note what actually happened there: the biggest workloads left one dedicated engine for another dedicated engine built on object storage — not back to Postgres. At that scale, specialized infrastructure genuinely wins.

What changed in pgvector (and why old blog posts mislead you)

Half the "pgvector vs X" comparisons still online describe a version that no longer exists. Current release is 0.8.5 (July 2026); the 0.8.x line has been stability work — HNSW vacuum fixes, Postgres 18 performance fixes. The features that killed the old criticisms shipped earlier:

• Iterative index scans (0.8.0, Oct 2024) ended the overfiltering problem — filtered vector queries no longer return starved result sets.
• halfvec and sparsevec (0.7.0) — half-precision indexes up to 4,000 dimensions and sparse-vector support; the "2,000-dimension cap" claim is stale.
• Parallel HNSW builds (0.6.0) — index builds stopped being single-threaded in January 2024.

Where Postgres honestly stops

The strongest critique ("The Case Against pgvector") is about the demo-vs-production gap: index maintenance under heavy churn, memory management, and filtering behavior at awkward selectivities. Those are real operational costs — my counterpoint is that a second database is also an operational cost, plus a sync pipeline, plus a consistency model between two systems. Below ~10M vectors the single-system simplicity wins on total cost of ownership. Above it, measure; far above it, don't fight physics.

The 2026 shakeout tells you the market's answer

• Pinecone: reportedly exploring a sale (Aug 2025); founder Edo Liberty stepped aside as CEO in Sept 2025; pricing is now serverless-only.
• Qdrant: $50M Series B (March 2026) — the surviving independents are consolidating around genuinely large workloads.
• Milvus 2.6: RaBitQ 1-bit quantization (~72% memory reduction) and removal of the Kafka/Pulsar dependency.
• Chroma: rebuilt as a distributed, object-storage serverless service (Chroma Cloud) — no longer the in-memory toy people remember.
• And the tell: Databricks bought Neon, Snowflake bought Crunchy Data, MongoDB bought Voyage AI. Everyone bought a Postgres or an embeddings company. Vector search became a feature of databases, not a database category. Even Elastic's CEO called vector databases "a feature, never a business."

Hybrid search: the BM25 truth

The real gap in native Postgres isn't vectors — it's lexical ranking. ts_rank is not BM25 (no corpus-level IDF), so pure-Postgres "hybrid search" tutorials quietly under-rank rare-term matches. In 2026 three extensions close the gap properly: pg_textsearch (TigerData, v1.0 GA April 2026), VectorChord-BM25, and ParadeDB's pg_search (note: Neon stopped offering pg_search to new projects in March 2026 — check your host). Dense + BM25 + a cross-encoder reranker is the highest-ROI retrieval upgrade I know, and it all runs inside Postgres now.

My production setup

Embeddings from Voyage, stored in pgvector with HNSW, hybrid-ranked with BM25, filtered by tenant and permission in the same SQL query, joined directly to the business tables the answer needs. When something misbehaves I EXPLAIN ANALYZE it like any other query. That debuggability — one system, one query planner, one backup story — is the feature no dedicated vector DB can sell me back.

FAQ

How many vectors can pgvector handle?

Comfortably into the low tens of millions on a well-provisioned node (~1M 1536-dim vectors per 16 GB RAM as a sizing rule). With pgvectorscale, credible benchmarks run to 50M+. Beyond that, dedicated engines earn their keep.

Is pgvector faster than Pinecone?

The famous "28x faster, 75% cheaper" Timescale benchmark was against Pinecone's now-retired pod tier — don't quote it as a current head-to-head. The honest claim: at small-to-mid scale, pgvector's latency is more than adequate and its total system cost is far lower because there is no second database.

Do I need a vector database for RAG?

No — you need retrieval. For most corpora that's Postgres with pgvector + BM25 + a reranker. Choose dedicated infrastructure for scale reasons, not because a RAG tutorial listed one.

What about the 2,000-dimension limit?

Stale: the vector type stores up to 16k dimensions, and halfvec indexes up to 4,000. Most production embeddings (768–1536 dims) never touch either limit.

Choosing a retrieval stack, or migrating off a vector DB you're outgrowing (in either direction)? Get in touch. Related: my full RAG stack for 2026 and agent memory on plain Postgres.