pgvector Ate The Vector Database Category

In 2023, choosing a vector database was a real decision. Pinecone or Weaviate or Qdrant or Milvus or Chroma. The pitch decks were full of HNSW vs. IVFPQ trade-offs. The blog posts compared recall@k at different ef_search values. Every RAG tutorial started with "first, pick your vector store."

By Q2 2026, my default answer is just use pgvector. So is most of the industry's. The category isn't dying loudly — it's dying quietly, the way Lucene-as-a-service died when Elasticsearch ate it.

The Trend That Killed It

Here's the line that explains the whole shift, from a vector DB roundup I read this month:

Vectors moved from being a database category to being a data type.

That's the entire story. A vector database in 2023 was a specialized system because Postgres couldn't do it well. By 2026, Postgres can do it well. The HNSW indexes in pgvector ship with parallel build, dynamic memory management, and quantization. The query planner integrates vector distance into existing query plans. You can JOIN against vectors. You can filter on metadata in the same query that ranks by similarity.

That last point is the killer. Most real RAG systems aren't "find me the top 10 nearest neighbors." They're "find me the top 10 nearest neighbors that belong to this user's tenant, are not soft-deleted, and were created in the last 30 days." Doing that across a dedicated vector store and a primary database means two queries, two consistency models, and a lot of glue code. Doing it in Postgres is one query.

The Numbers Now

The benchmark picture has flipped completely from 2023:

• Under 10M vectors — pgvector with a tuned HNSW index queries in 5-20ms at 95%+ recall, on hardware you already have. It often beats hosted vector stores because there's no network hop.
• At 100M vectors — pgvector needs careful tuning, but it works. Pinecone and Weaviate maintain recall more easily without tuning, but the cost gap is real: ~$700/month on Pinecone vs. under $100 on a self-hosted pgvector setup.
• Beyond 100M vectors — specialized stores still win on operational ease. This is the only segment where the category remains defensible.

The honest summary: pgvector is good enough for 95% of production RAG workloads, and the 5% it doesn't cover are companies large enough to afford a dedicated infra team.

Why It Won

Three reasons, in increasing importance:

1. The default is hard to beat. Postgres is already in your stack. Adding an extension is CREATE EXTENSION vector;. Adding a new database is a procurement conversation, a deployment, a backup story, a monitoring integration, an on-call rotation, and a year of "wait, which database has the latest version of this user's data?"

2. The hybrid search story is structural. A vector database can bolt on full-text search and metadata filtering. A relational database with a vector index is already a hybrid search engine. The architectural advantage compounds with every feature.

3. The LLM-shaped use case is JOIN-heavy. Modern retrieval looks less like "find similar documents" and more like "find chunks belonging to documents the user has access to, ranked by similarity and recency, with the parent document's metadata included." This is exactly what Postgres was built for.

Pinecone tried to build all three. Weaviate tried to build all three. They succeeded technically. They lost on the integration argument, because Postgres was already integrated.

What This Means For The Other Vendors

I'm not predicting graveyards. The dedicated vector stores still have homes:

• Pinecone — survives as the "managed default" for teams that don't want to run anything. The pitch shifts from "best performance" to "best ergonomics." Their pricing has already moved that direction.
• Qdrant — survives as the high-performance option for genuinely large workloads. The Rust implementation is the moat.
• Weaviate — leans harder into hybrid search and knowledge graph features. The vector part becomes table stakes.
• Milvus — survives in the enterprise/on-prem segment where data sovereignty is the dominant concern.
• Chroma — the local-first / embedded use case is real, but small. Survives as "SQLite for vectors."
• Turbopuffer / LanceDB / others — the next wave of S3-native designs has interesting economics, especially for cold storage. Watch this segment.

But the default has shifted. New RAG projects don't start with "which vector DB?" anymore. They start with "we already have Postgres" and move on.

What I Actually Run

The current stack for every project that needs retrieval:

• Postgres 17 with pgvector 0.8+ for the vector index
• HNSW (not IVFFlat) — the build time is acceptable now and the query latency is dramatically better
• A single embeddings table joined to the source tables that own the actual content
• hnsw.ef_search tuned per-query based on the recall the workload needs, not globally
• pg_trgm alongside vectors for hybrid keyword + semantic search — the recall improvement is worth the storage cost
• Backup: same pg_dump flow as everything else, because it's the same database

The whole thing fits inside a Postgres container. The whole thing speaks the same SQL my product already speaks. The whole thing costs nothing extra to operate.

The Generalizable Lesson

Every few years, a "category" gets created when an existing tool can't quite do something well. NoSQL got created when relational databases couldn't handle web-scale. Search engines got created when SQL LIKE was too slow. Vector databases got created when Postgres couldn't do nearest-neighbor at scale.

In every case, the same pattern played out: the existing tool caught up faster than the new category expected, and the integration advantage swallowed the specialization advantage. Postgres has JSON now. Postgres has full-text search now. Postgres has vectors now. Postgres will probably have whatever the next "category" is, three years after it gets invented.

The lesson for builders: be skeptical of new database categories that compete with capabilities Postgres could plausibly add. Postgres' core team is patient, the community is huge, and the integration surface is unbeatable. If the new category's only moat is "we do X better than Postgres," the moat has a five-year half-life.

If you're picking a vector database in 2026, start with pgvector. Switch when it hurts. For most teams, it never will.

The category isn't dead. The category just isn't a category anymore.

Sources:

• pgvector vs Pinecone: Which Vector Database to Choose in 2026 (Encore)
• What's Changing in Vector Databases in 2026 (DEV)
• Vector Databases: When pgvector Beats Pinecone (and When It Doesn't)
• Best Vector Databases in 2026 (MarkTechPost)