Vector Databases in 2026: Do You Need One, or Is pgvector Enough?

Every few weeks someone asks me which vector database they should pick for a RAG feature, and my first answer is usually a question back: how many vectors, how many tenants, and do you already run Postgres? Most of the time the honest answer is that a vector database is a feature, not a product category, and the one you already operate will do. But 2026 has been a busy year for the products that disagree: Amazon turned an S3 bucket into a vector index, Milvus shipped a lake-native 3.0, Qdrant raised a Series B, Notion published how it cut search spend by moving off a dedicated-cluster design, and the most cited benchmark stopped being maintained. This post walks through what changed in vector databases this year, what each option costs, why the published benchmarks rarely answer your question, and where the line sits between "pgvector is enough" and "you need something else".

What changed in vector databases in 2025 and 2026

The market story of the last eighteen months is consolidation around two shapes, Postgres and object storage, with the specialist databases squeezed in between.

On the Postgres side, the large data platforms bought their way in. Databricks paid a reported $1 billion for Neon in May 2025 and Snowflake bought Crunchy Data a few weeks later for a price the Wall Street Journal put at about $250 million, as Constellation Research summarised. Meanwhile pgvector itself kept shipping: 0.8.0 in October 2024 added iterative index scans for filtered queries, and the 0.8.x line has been patch releases since, up to 0.8.7 on 1 October 2026, several of them fixing HNSW vacuuming and IVFFlat build bugs.

On the specialist side, Pinecone, the company that popularised the term, changed leadership: founder Edo Liberty moved to chief scientist and Ash Ashutosh became CEO on 8 September 2025. Qdrant raised a $50 million Series B led by AVP on 12 March 2026, citing more than 250 million downloads. Milvus 3.0.0 landed on 29 July 2026 with "External Collections" that index files in a data lake in place rather than copying them in.

And object storage arrived as a first-class vector store. Amazon S3 Vectors went GA on 2 December 2025 with up to 2 billion vectors per index, 20 trillion per bucket, and latency of about 100 ms for frequent queries and under a second for infrequent ones. turbopuffer, which built a search engine on S3 from the start, published an ANN v3 design in January 2026 claiming 200 ms p99 over 100 billion 1,024-dimension vectors.

The customer migration that made people pay attention was Notion's. Its February 2026 write-up describes moving from dedicated "pod" clusters to a serverless tier in May 2024 (a 50 percent cost cut from peak), then to turbopuffer between late 2024 and January 2025 (another 60 percent off search engine spend), with p50 query latency falling from 70 to 100 ms to 50 to 70 ms. Notion does not name the first provider in that post.

Vector database comparison table for 2026

Prices change monthly and every vendor bills on a different unit, so treat this as an anchor, not a quote. I checked each source on 20 October 2026.

Option	Shape	Latest release	Price anchor	Source
pgvector	Postgres extension, HNSW and IVFFlat	0.8.7 (1 Oct 2026)	Free; you pay for Postgres	changelog
pgvectorscale	Postgres extension, StreamingDiskANN	0.9.1 (4 Sep 2026)	Free	GitHub
Pinecone	Managed serverless	SaaS	Standard: $50/month minimum, $0.33/GB-month, $16 to $18 per million read units	pricing
turbopuffer	Managed, object-storage first	SaaS	Launch: $16/month minimum, $0.33/GB storage, $2/GB written	pricing
Amazon S3 Vectors	S3 bucket type	GA 2 Dec 2025	$0.06/GB-month, $0.20/GB PUT, $2.50 per million queries plus a per-TB scan fee	S3 pricing
Qdrant	Open source (Rust), plus cloud	1.19.2 (5 Oct 2026)	Free self-hosted	GitHub
Milvus	Open source, distributed, plus Zilliz Cloud	3.0.3 (14 Oct 2026)	Free self-hosted	GitHub
Weaviate	Open source (Go), plus cloud	1.40.1 (13 Oct 2026)	Free self-hosted	GitHub
Elasticsearch	Search engine with dense_vector	9.5.5 (6 Oct 2026)	Free tier plus licence	dense_vector docs
OpenSearch	Search engine with k-NN plugin	3.9.0 (29 Sep 2026)	Free	GitHub

Two details in that table matter more than the logos. First, Pinecone and turbopuffer list the same $0.33 per GB-month for storage, while S3 Vectors lists $0.06, so the price gap between serverless products now lives mostly in query and write billing, not storage. Second, the search engines quietly became competitive vector stores: Elasticsearch made its BBQ binary quantization the default for float vectors of 384 or more dimensions in 9.1, and from 9.4 defaults to a disk-based BBQ index where the licence allows, per its mapping docs. If you already run Elasticsearch for text search, you already own a vector database.

Object storage ate the vector database

The architectural shift is easier to see than to read about. The first generation of managed vector databases held the index in RAM or on local SSD on nodes you paid for around the clock. The 2026 generation keeps the durable copy in object storage and caches hot data near compute, which is why Notion could cut spend while scaling up.

The trade is cold latency. A namespace nobody has queried for an hour has to come back from S3, and S3 Vectors' own numbers say under a second for those. For a multi-tenant SaaS where most tenants are idle most of the time, that is a bargain. For a recommendation API with a 50 ms budget on every request, it is a problem you will have to warm around. This is the same scale-to-zero arithmetic I wrote about for compute: idle capacity is cheap to drop and expensive to bring back.

Can you trust vector database benchmarks?

Mostly no, and not because anyone is lying. The two benchmarks people cite measure narrow things.

ANN-Benchmarks compares index algorithms, including pgvector, on datasets such as glove-100 and sift-128, with results "as of April 2025" on an r6i.16xlarge where "all benchmarks are single-CPU". Its README now says the project "is no longer actively maintained" and points people at VIBE instead. It tells you about the recall and speed curve of an algorithm in a loop, and nothing about filters, writes, tenants or network hops.

VectorDBBench is closer to production, and its 2.0.0 release in September 2026 added cases for time until inserted vectors become searchable, cold first-query latency, and the cost of returning metadata instead of bare IDs. It is also maintained by Zilliz, the company behind Milvus, so read its leaderboards the way you would read any vendor's.

Vendor claims are the third category. pgvectorscale's README says that on 50 million 768-dimension Cohere embeddings it achieves "28x lower p95 latency and 16x higher query throughput" than Pinecone's storage-optimised s1 index at 99 percent recall. That was a comparison against a Pinecone tier that the serverless product has largely replaced, published by the vendor of the winning extension.

The parameters you choose swing results more than the product. On my laptop (an M3 Pro, Postgres 18.4, pgvector 0.8.2, 100,000 synthetic 384-dimension vectors in 1,000 clusters), an HNSW index with default build settings returned 85 percent recall@10 at the default hnsw.ef_search of 40 and 99 percent at 200; an identical rebuild of the same index gave 92 percent at 40, because graph construction is not deterministic. On uniformly random vectors, which have no neighbourhood structure at all, the default settings gave 6 percent. A benchmark that does not tell you the dataset, the recall target and the tuning is a number without a unit. The sibling guide has the scripts.

When is pgvector enough?

My rule of thumb, which is opinion rather than measurement: if your vectors fit comfortably on one Postgres primary with the HNSW index in memory, and you have fewer tenants than you can partition, pgvector is enough and the operational savings dominate everything else. You get transactions, joins against your real data, one backup and point-in-time recovery story (pgvector writes to the WAL, so replicas work), and row-level security that a separate vector store cannot see.

The hard limits from the pgvector README are generous for most RAG work:

• vector columns store up to 16,000 dimensions, but HNSW and IVFFlat index only up to 2,000. halfvec indexes up to 4,000 and binary quantized bit up to 64,000.
• A non-partitioned table is capped at 32 TB by default.
• Filtering happens after the index scan. With ef_search at 40 and a filter matching 10 percent of rows, you get about 4 results on average unless you enable iterative scans.
• Sharing one approximate index between tenants lets one tenant's vectors affect another's recall and speed. The README's answer is list partitioning or separate tables.

The configuration I would start from for a new RAG table looks like this. It halves the index with halfvec, keeps full precision in the table for re-ranking, and turns on iterative scans so filtered queries do not silently return short.

-- Postgres 18 with pgvector 0.8.7 (image: pgvector/pgvector:0.8.7-pg18)
CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE chunks (
  id          bigserial PRIMARY KEY,
  tenant_id   int    NOT NULL,
  doc_id      bigint NOT NULL,
  body        text   NOT NULL,
  embedding   vector(1536) NOT NULL          -- full precision kept for re-ranking
);

-- Build after bulk load; give the build enough memory and workers.
SET maintenance_work_mem = '4GB';           -- must hold the HNSW graph
SET max_parallel_maintenance_workers = 7;   -- plus the leader

-- Index a half-precision expression: about half the size of a vector index.
CREATE INDEX CONCURRENTLY chunks_embedding_hnsw
  ON chunks USING hnsw ((embedding::halfvec(1536)) halfvec_cosine_ops)
  WITH (m = 16, ef_construction = 64);      -- the defaults; raise only if recall is low

-- Per query: more candidates, and keep scanning until the filter is satisfied.
BEGIN;
SET LOCAL hnsw.ef_search = 100;
SET LOCAL hnsw.iterative_scan = relaxed_order;
SELECT id, doc_id
FROM chunks
WHERE tenant_id = $1
ORDER BY embedding::halfvec(1536) <=> $2::halfvec(1536)
LIMIT 10;
COMMIT;

On that laptop test, a halfvec index was 112 MB against 195 MB for the full-precision index, and a binary quantized index was 33 MB, with recall recovered to 99 percent by re-ranking 100 candidates against the full vectors. Those are small synthetic numbers; the ratios, not the absolute values, are the point.

If you need hybrid search, Postgres has had tsvector for two decades. The agent memory post covers a benchmark where plain BM25 beat every commercial memory product on retrieval, which is a good reason to put keyword search next to your vectors before you buy anything.

When does a dedicated vector database earn its keep?

There are real cases, and they are mostly about shape rather than size.

Many cold tenants. If you have hundreds of thousands of namespaces and most are idle, partitioning Postgres into that many pieces is miserable, and paying for RAM to hold them all is waste. This is exactly where turbopuffer's customer list sits: its customers page shows Notion at more than 10 million namespaces and Linear at more than 4 million.

Billions of vectors with a write firehose. Notion reports 1 GB/s write peaks on that same page. A single Postgres primary is not where I would send that.

You already run a search cluster. If Elasticsearch or OpenSearch already holds your documents, adding a dense_vector field is less work than synchronising a second store.

Your data lives in a lake. Milvus 3.0's external collections and S3 Vectors' integration with Bedrock Knowledge Bases and OpenSearch are aimed at teams whose source of truth is Parquet on S3, not rows in Postgres.

Nobody on the team wants to operate Postgres. That is a legitimate reason. A managed serverless index with a $16 or $50 monthly floor costs less than an engineer's afternoon.

What does not justify a dedicated database on its own: "we might scale", a benchmark chart, or an embedding model with 3,072 dimensions (index it as halfvec, or truncate it if the model supports shorter outputs).

The cost nobody puts in the comparison

The bill that surprises teams is rarely the vector store. It is the second copy of the data, and the pipeline that keeps it in sync with the source. Every dedicated store means a change-data-capture job, a backfill path, deletes that have to propagate for compliance, and a reconciliation check for when they do not. That is platform work, and it is the part that breaks at 2 a.m. In the agent era, where retrieval feeds a model that will confidently answer from a stale chunk, a sync lag is a correctness bug, not a performance one. The FinOps for AI post makes a related point about token spend: the line items that hurt are the ones nobody owns.

FAQ

Do I need a vector database for RAG?

Usually not at the start. If you run Postgres, pgvector handles millions of embeddings with HNSW indexes, SQL filters and joins, and it keeps your access controls in one place. Move to a dedicated or object-storage-first store when tenant count, write volume or cold data make Postgres awkward, not before.

Is pgvector production ready in 2026?

Yes. It is at 0.8.7, writes to the WAL so replication and point-in-time recovery work, and is offered by the major managed Postgres services. Watch the 2,000-dimension index limit for vector, enable iterative scans for filtered queries, and keep the HNSW index in memory.

Is Amazon S3 Vectors a replacement for Pinecone?

For large, infrequently queried collections it can be, at $0.06 per GB-month of storage and up to 2 billion vectors per index. For latency-sensitive search it is not a drop-in: AWS quotes about 100 ms for frequent queries and under a second for infrequent ones, and top-k is capped at 100.

Which vector database benchmark should I trust?

None as a final answer. ANN-Benchmarks is unmaintained and single-CPU; VectorDBBench is more realistic but vendor-maintained. Run your own embeddings, your own filters and your recall target through two candidates for a day; that beats any public chart.

This quarter I would do the boring thing: keep vectors in Postgres with pgvector, index them as halfvec, turn on iterative scans, add a tsvector column for keyword search, and write a nightly job that compares approximate results against exact search so recall is a metric rather than a hope. I would only put S3 Vectors or turbopuffer on the shortlist the day tenant count or cold data made partitioning painful. For the hands-on tuning steps, see the pgvector HNSW tuning guide, and for the pipeline around it, the Postgres RAG pipeline guide.

Related: Agent Memory in 2026, What Scale to Zero Cost Me to Build and LLM Inference in 2026.