Pick a Vector Database by What Breaks First

Almost every retrieval system should start with pgvector in the Postgres you already run, and the selection question is not "which vector database is fastest" but "which failure mode reaches me first". Published recall and QPS numbers converge across engines at the scales most teams actually operate. What does not converge is what happens when you add a tenant filter to every query, when the index needs a rebuild during business hours, or when the HNSW graph stops fitting in RAM. Those are the events that force a migration, and each engine fails at a different one.

So the honest way to compare vector stores is to work backwards from the break. Pick the failure you will hit first, then pick the engine that does not have it. Everything else is a feature grid.

The four things that actually break

Across production RAG and agent-memory systems, four symptoms account for nearly every migration off the initial choice:

• Index build and rebuild time. You change the embedding model, or the dimension, or the distance operator, and now you need to rebuild an approximate-nearest-neighbour index over every row. At a million vectors this is coffee. At fifty million it is a maintenance window, and you need to decide whether the old index serves traffic while the new one builds.
• Filtered search recall. Almost nobody runs an unfiltered vector query in production. Real queries are "nearest neighbours where tenant_id = X and status = active and updated_at > Y". Graph indexes are built for the unfiltered case, and a selective filter can make an ANN search return fewer than the k rows you asked for, silently. That is a correctness problem dressed as a relevance problem.
• Graph memory versus RAM. HNSW is a graph, and it wants to live in memory. When the graph plus your working set exceeds what the instance has, latency does not degrade gracefully, it falls off a cliff as the machine starts reading index pages from disk on every probe.
• Freshness lag under write load. Agent memory and support tooling write constantly. Every insert mutates the graph, index maintenance competes with query traffic, and the gap between "we stored the fact" and "the fact is retrievable" starts to matter for correctness rather than for feel.

Note what is not on that list: raw queries per second. If you are serving retrieval to a model that then spends two seconds generating, a ten millisecond difference in search latency is noise. The latency that hurts in RAG lives in the number of round trips, not in the ANN probe.

pgvector: the correct default, and its real ceilings

The case for pgvector is not that it wins benchmarks. It is that your embeddings live in the same transaction as the row they describe, your filters are ordinary SQL against columns that already have indexes, your backup and point-in-time recovery story is the one you already operate, and your on-call already knows how to read EXPLAIN. That combination is worth a great deal of p99.

The ceilings are specific and worth memorising, because vague fear of them causes more premature migrations than the ceilings themselves ever do:

• Dimension limits are index limits, not column limits. A vector column accepts up to 16,000 dimensions, but HNSW and IVFFlat only index up to 2,000. Use halfvec (16-bit floats) and you index up to 4,000 dimensions at roughly half the storage. bit indexes up to 64,000 dimensions for binary quantization, and sparsevec handles up to 1,000 non-zero elements. A 3,072-dimension embedding is not a reason to leave Postgres, it is a reason to cast to halfvec in the index expression.
• Filtered queries stopped being a cliff in 0.8.0. The old failure was real: an HNSW scan returned its ef_search candidates, your WHERE clause deleted most of them, and you got three rows back when you asked for ten. pgvector 0.8.0 added iterative index scans, which keep scanning until they have enough surviving rows. hnsw.iterative_scan = strict_order preserves exact distance ordering, relaxed_order trades a little ordering for better recall. If your mental model of pgvector's filtering is from 2024, it is out of date.
• Build memory is the thing that actually bites. HNSW builds in memory when the graph fits inside maintenance_work_mem, and falls back to a much slower on-disk path when it does not. The fix is to raise it for the build and use parallel workers, but there is a size past which you are planning a rebuild rather than running one.
• Noisy neighbours are architectural. An ANN build saturating CPU on the instance that serves your checkout flow is the failure mode that has nothing to do with vectors. A read replica or a separate instance solves it, which is also the moment pgvector stops being free.

On AWS specifically, Aurora PostgreSQL with pgvector is a first-class Bedrock Knowledge Bases vector store, so choosing it costs you no managed-RAG features. I wrote up the cost side of that in the OpenSearch Serverless to Aurora migration post, with one caveat below: the OpenSearch side of that comparison changed in May 2026.

OpenSearch: you are buying a search engine, so use it as one

Choosing OpenSearch purely as a vector store is the expensive way to get vector search. Choosing it because you need search, and vectors are one of the things you are searching with, is a different and much better decision.

What it gives you that a pure vector store does not: real lexical search alongside ANN, so hybrid retrieval combining BM25 with vector similarity is a query, not an architecture. Exact keyword matching for the part numbers, error codes, and identifiers that embeddings are famously bad at. Aggregations, faceting, and a filtering engine built for high-cardinality attributes rather than bolted on. And binary vectors, which on Bedrock Knowledge Bases only the two OpenSearch options support.

The argument against it has historically been the floor: OpenSearch Serverless billed in OCUs with a production minimum that cost real money before you indexed a single document. That is the argument my migration post was built on, and it needs a correction. The next generation of OpenSearch Serverless went generally available on 28 May 2026 with compute and storage fully decoupled, scale-to-zero, and autoscaling AWS describes as twenty times faster than the previous generation. AWS claims up to 60 percent savings against provisioning a cluster for peak load. If your workload is bursty, and agentic retrieval is extremely bursty, the old floor argument no longer applies in the form I made it.

What still breaks: it is a distributed system with shards, replicas, and a cluster state, and it will eventually ask you to think about all three. Shard sizing for vector workloads is not the same as for logs. And a rebuild is a reindex, which means capacity planning for two copies of the index.

S3 Vectors: a storage tier that answers queries, not a serving tier

S3 Vectors reached general availability on 2 December 2025 at forty times the preview scale: up to two billion vectors per index and ten thousand indexes per vector bucket, with seventeen more regions added in March 2026. AWS puts the cost reduction against running a vector database at up to 90 percent, and the reason is structural rather than promotional: there is no cluster, no provisioned compute, and no idle charge.

The number that decides whether it fits is the latency profile. AWS documents infrequent queries returning in under a second, and more frequent queries at roughly 100 milliseconds or less. Read that as a warm-cache effect, and then be honest about your traffic: a support assistant asked forty questions an hour is not keeping anything warm. Sub-second is fine for a nightly summarisation job and wrong for an interactive chat where the model then needs its own two seconds.

Where it is genuinely the right answer: cold or archival vector tiers, per-tenant indexes where the tenant count is large and each tenant's traffic is sparse, cost-driven Bedrock Knowledge Bases with tolerant latency budgets, and anything where the alternative was paying for an idle cluster. It composes well as a second tier under a hot store, which is how I would use it rather than as a wholesale replacement.

Qdrant, Milvus, Pinecone: when the payload wins

You leave Postgres for a dedicated engine when the vector workload has stopped being a feature of your application and become the application. Three shapes of that:

Qdrant is the one to reach for when filtering is the problem. Its payload indexes and filterable HNSW are designed for the case pgvector's iterative scan merely survives: highly selective filters on every query, at high rates. It also ships scalar, product, and binary quantization, which is the practical way to keep a large index resident in memory. For a multi-tenant agent memory store with per-tenant filters on every read, this is a defensible reason to run another database.

Milvus is the billion-scale answer. Disk-based indexing (DiskANN) means the working set does not have to fit in RAM, which is what changes the hardware bill at that size. The trade is operational: it is a distributed system with separate coordinator, query, data, and index roles, and running it in production is a staffing decision before it is a technical one. Below a few hundred million vectors, that complexity buys you very little.

Pinecone is the buy-instead-of-build option, and it should be evaluated the way you evaluate any SaaS: on the operational burden it removes rather than on latency. Serverless pricing decouples storage from reads and writes with no idle cost, which suits spiky workloads and makes small deployments genuinely cheap. What you give up is control over the failure modes, and you take on egress and vendor coupling. It is also a supported Bedrock Knowledge Bases store, so it is not an exit from the AWS-managed RAG path.

The long tail, briefly

Weaviate is the closest thing to a batteries-included RAG store: built-in vectorisation modules, hybrid search, and a schema-first model. Attractive if you want opinions supplied, less so if you already have an embedding pipeline. Chroma is a prototyping tool that is honest about it, and every serious deployment I have seen eventually migrated off it. Redis with vector similarity is excellent when the vectors are ephemeral, sessions, short-term agent memory, semantic caches, and terrible as a system of record. MongoDB Atlas Vector Search is to Mongo what pgvector is to Postgres: correct if your documents already live there, and a poor reason to adopt Mongo if they do not. Both Redis Enterprise Cloud and MongoDB Atlas are supported Bedrock Knowledge Bases stores.

The decision table

The triggers that actually mean "leave pgvector now"

Not scale in the abstract. These:

• Your HNSW rebuild no longer fits in an acceptable maintenance window, and you have already raised maintenance_work_mem and used parallel workers.
• Filtered recall is still short after enabling iterative scans and tuning ef_search, because your filters are selective enough that the graph is the wrong structure.
• The index working set exceeds instance memory and the next instance size up costs more than a dedicated engine would.
• Vector search is starving your transactional workload, and a read replica is not enough separation.
• You need hybrid lexical plus vector ranking as a first-class query rather than as two searches you merge in application code. That one points at OpenSearch specifically.

If none of those is true, the migration you are planning is a preference, not a requirement. The team that ships a working retrieval layer on the database it already runs, and moves only when one of those triggers fires, gets to production considerably sooner than the team that spent the first sprint choosing.

The takeaway

Start on pgvector, and know its four ceilings precisely enough that you can tell a real limit from folklore. Move to OpenSearch when you need search rather than similarity, and re-run the cost comparison against the next-generation serverless offering rather than the old OCU floor. Use S3 Vectors as a cold tier and for sparse per-tenant indexes, not as an interactive serving path. Reach for Qdrant when filtering dominates, Milvus past the point where RAM sets the bill, and Pinecone when you would rather buy the operations than run them. Pick by the break you will hit first, because that is the only variable in this comparison that differs meaningfully between engines.

Read this next

• Agent Memory Is a Database Problem, Not a Prompt Problem, on why the storage layer decides what your agent can remember.
• Knowledge Base Chunking Is Where Your RAG Quality Dies, on the retrieval problem no vector database fixes for you.

For the infrastructure side of running Postgres and search clusters in production, the cloud field notes live at ercan.cloud, and the hub is at ercanermis.com.

References

• pgvector on GitHub, vector types, index types, and dimension limits.
• pgvector 0.8.0 release announcement, iterative index scans and filtering improvements.
• The next generation of Amazon OpenSearch Serverless is now generally available, AWS What's New, 28 May 2026.
• Amazon S3 Vectors is now generally available with 40 times the scale of preview, AWS What's New, 2 December 2025.
• Working with S3 Vectors and vector buckets, Amazon S3 User Guide.
• Prerequisites for using a vector store you created for a knowledge base, Amazon Bedrock User Guide.
• Approximate k-NN search, OpenSearch documentation.
• Filtering, Qdrant documentation.
• DiskANN-based on-disk index, Milvus documentation.
• Pinecone pricing, serverless read unit, write unit, and storage model.