Choosing a Vector Database Without Overthinking It

If you already run Postgres, install pgvector and move on. That's the answer for roughly 80% of the people reading this, and you can stop here.

I mean that literally. Most teams evaluating vector databases have a corpus of somewhere between ten thousand and a few million chunks, single-digit queries per second, and a product that hasn't launched. For that shape of problem the extra database is a liability, not an advantage. The interesting part of your RAG system is the chunking and the retrieval quality, not the storage engine.

Below is what would actually change my answer, and then the real options if it does.

What would move me off the default

You don't have Postgres. Obvious, but it decides a lot. If your stack is Mongo or DynamoDB and adding Postgres just for vectors is a whole new operational surface, then a purpose-built vector store is a cleaner addition.

You need serious hybrid search. Keyword plus vector, fused and reranked. pgvector plus tsvector gets you a workable version of this. If relevance is your product rather than a feature of your product, a purpose-built engine will do it better.

Very high write throughput on the index. Constant inserts with immediate searchability is where Postgres index maintenance starts to hurt.

Billions of vectors. Not millions. Billions. Almost nobody reading this is here.

Notice what isn't on that list: "we might get big someday." Scale is the reason people give and almost never the reason that decides it.

The options, grouped honestly

Postgres with pgvector. One database. Your vectors sit in a table with a foreign key to the row they describe. You filter with WHERE, join to your users table, and wrap embedding writes in the same transaction as the content write. HNSW indexes are good. This is the boring correct answer and I've stopped apologising for it.

Supabase. pgvector with the setup done for you, plus auth and storage. If you're a small team already leaning that way it's the fastest path from nothing to working retrieval. I've compared it against the alternative in more detail elsewhere.

Managed vector services (Pinecone and friends). You pay to never think about index tuning, replication, or scaling. Genuinely good at that. The cost is that your vectors live somewhere your relational data doesn't, and pricing is per-index-per-hour rather than per-query, so a small idle index still bills. Expect somewhere in the tens of dollars a month for a starter production index and a lot more once you have several, though check current pricing yourself because it changes.

Self-hosted Qdrant, Weaviate, Milvus. Qdrant is the one I reach for here: fast, sensible filtering, a single binary that doesn't fight you. Weaviate has a richer feature surface and more concepts to learn. Milvus is built for the billions-of-vectors case and its operational footprint reflects that — don't run it because it benchmarks well, run it because you have that problem. All three mean you now own a stateful service: backups, upgrades, memory sizing, monitoring.

Search engines that grew vectors: Elasticsearch, OpenSearch. Underrated if you already operate one. You get mature BM25, real filtering, aggregations, and vector search in the same query. If your product already has a search box backed by Elastic, adding vectors there is far less work than adding a second system. If you don't already run it, don't start now for this.

What actually decides it

Metadata filtering. Real queries are never "find similar chunks." They're "find similar chunks in this workspace, from documents this user can read, not archived, updated in the last year." How a store handles pre-filtering versus post-filtering matters enormously. Post-filtering means you ask for the top 50 neighbours, throw most away, and sometimes end up with three results. In Postgres this is a WHERE clause the planner understands, which is a genuinely large advantage.

Hybrid search. Pure vector search fails badly on exact identifiers. Someone searches an error code, a SKU, a surname, and semantic similarity returns things that are about the same topic while missing the literal match. Every serious retrieval system I've built ended up combining keyword and vector scores. Ask how a candidate does this before you ask about its recall benchmarks.

Sync. This is the one I underrate least these days, because I got burned. Two stores means two writes, and two writes means drift.

The mistake that changed my default

On a client's document search feature I put content in Postgres and vectors in a hosted vector service, because that's what the tutorials did. It worked immediately and looked clean.

Then deletes started failing silently. A document got removed from Postgres, the vector delete threw, nobody caught it, and the chunk stayed in the index. Users searched and got summaries of documents that no longer existed, including one that had been deleted specifically because it shouldn't have been shared. Fixing it meant a reconciliation job that walked both stores and repaired differences, which is infrastructure I built for free because of a choice I made in an afternoon.

Vectors next to relational data in the same transaction removes that entire class of bug. Not reduces — removes. That's worth more than any recall number in a vendor comparison.

Where pgvector stops being the right answer

I'm not pretending it scales forever. The real limits:

• Index build time. Building HNSW over several million vectors is slow and memory-hungry. Plan it, don't discover it during a migration window.
• Memory. For fast search the index wants to live in RAM. Millions of 1536-dimension vectors is real memory, and it competes with the buffer cache your normal queries need. Cutting dimensions helps more than people expect.
• High QPS. Postgres serving hundreds of vector queries per second alongside your transactional load will make you choose between them. That's when a separate service earns its keep.
• Billions of vectors. Genuinely out of scope. Go get Milvus.

Every one of those is a problem you'll see coming with normal monitoring, and every one arrives long after you've learned what your product actually needs. Migrating later costs you a re-embed and a week. Choosing wrong now costs you months of carrying a system you didn't need.

Pick the database your data already lives in, spend the saved time on chunking and reranking, and let the query latency graph tell you when it's time to move. It'll be later than you think, and by then you'll know exactly what to move to. Same argument I make about Postgres versus Mongo, for the same reason.