Choosing a Vector Database Without Losing Your Mind

July 6, 2026 · 6 min read · AI & Data

Key Takeaways

Start on pgvector; most business search never outgrows it.
Four questions decide it: vector count, QPS, ops capacity, filter complexity.
Real triggers for a dedicated engine: 10M+ vectors, strict latency at high QPS, brutal filters.
Pick Qdrant for lean self-hosting, Weaviate for batteries included, Pinecone for zero ops.
Store embeddings in object storage and wrap the index in 50 lines of API so migration costs a week.

Somewhere right now, a technical lead has 47 browser tabs open: benchmark posts, vendor comparison pages, three Hacker News threads, and a pricing calculator that assumes they know their queries per second, which they do not. They were asked to "set up the vector database" for a RAG project last Thursday.

I've watched this movie. It ends with either a six-week infrastructure odyssey or a panic purchase of an enterprise plan sized for a streaming giant, for a company that wants to search 8,000 PDFs.

Here's how to choose a vector database the boring way, meaning the way that ships.

The honest answer: for most business use cases, pgvector on the Postgres you already run is the right vector database, and you should start there. Move to a dedicated engine like Qdrant, Weaviate, or Pinecone only when you hit real triggers: tens of millions of vectors, sustained high query volume with strict latency, or metadata filtering heavy enough to make Postgres sweat. Choose by asking four questions, not by comparing feature matrices.

What a Vector Database Actually Does

A sixty-second version, because the marketing makes it sound mystical. Your documents get chopped into chunks, each chunk gets turned into an embedding (a list of numbers representing meaning), and the database's job is: given a new embedding, find the closest stored ones fast. That, plus the boring bits like updates, deletes, metadata filters, and backups, is the entire job description.

The boring bits are what you're actually buying. Every option finds nearest neighbors; that's table stakes. They differ on operational shape: who runs it, how it scales, what happens at 2am, and how gracefully it handles "find me chunks like this, but only from contracts signed after 2023 that mention indemnification."

How to Choose a Vector Database: The Boring Framework

Four questions, in order. Write your answers down before opening any vendor site:

How many vectors? A chunk is roughly a paragraph. A hundred thousand documents might be 2 to 5 million vectors. Under about 5 million, almost everything works, including Postgres.
How many queries per second? Internal tools serving 50 employees live in single-digit QPS. A customer-facing product feature might see hundreds. Single digits change the answer completely.
Who runs it at 2am? A managed service costs money and zero pager duty. Self-hosting is cheap on the invoice and expensive on the humans. Be honest about which humans you have.
How gnarly are your filters? Pure similarity search is easy for everyone. Similarity plus five metadata conditions is where the lightweight options start wheezing.

This framework beats the feature matrix because the feature matrix answers a question you don't have. You don't need the "best" vector database. You need the least infrastructure that handles your actual numbers.

pgvector: The Default Answer

If your data already lives in Postgres, and for most small and mid-size companies it does or should, pgvector is the default, and it's a good default. Your vectors sit next to your rows. Filters are just SQL. Backups are the backups you already have. There's no new system to learn, secure, patch, and explain to the next hire.

An illustrative reality check: a composite client ran document search over about 2 million chunks on pgvector with sub-100-millisecond queries and zero new infrastructure. That's a company knowledge base, a support-docs search, and a contract Q&A system, all inside the database they already paid for. The scale ceiling everyone warns about turned out to be ten times their actual needs.

One more underappreciated benefit: transactions. When a document updates, the row and its vectors update together, atomically. In a two-system world, you get to enjoy eventual-consistency bugs at the exact moment a user reports them. Ask me how I know.

When a Dedicated Database Earns Its Keep

Dedicated engines exist for a reason, and the reason is real scale or real constraints. Three triggers justify the move:

The Scale Trigger

Tens of millions of vectors, or a collection growing fast enough that you'll be there within a year. Postgres will fight gamely, but purpose-built indexes with proper HNSW tuning, quantization, and sharding win at that size, and the gap widens with every order of magnitude.

The Ops Trigger

Sustained high QPS with strict latency, like a customer-facing semantic search box or an agent that queries on every step, is where a dedicated, tunable service pays off. The same applies when your metadata filters are complex enough that you're basically running a search engine; at that point, use the search engine. If your AI agents are hitting the index on every production step, latency stops being a nice-to-have.

What isn't a trigger: "it feels more serious," "the vendor demo was slick," or "we might be huge someday." Premature infrastructure is how small teams end up maintaining a distributed system instead of shipping the feature the system was for.

Qdrant, Weaviate, and Pinecone in Plain Words

If you do hit a trigger, the shortlist is mercifully short, and each option has a distinct shape:

Qdrant: the lean, self-hostable option. Runs happily on one machine, strong filtering, predictable behavior. Pick it when you want control without a platform team.
Weaviate: the feature-rich one, with hybrid search, modules, and built-in vectorization options. Pick it when you want batteries included and accept the operational weight the batteries bring.
Pinecone: the fully managed one. You get an endpoint, they get the pager. Pick it when ops capacity is your scarcest resource and the invoice is acceptable.

Notice what's absent: benchmark numbers. At the scale where you're choosing among these three, your bottleneck is almost never raw recall-per-millisecond; it's filters, indexing time, and your team's ability to operate the thing. Choose on shape, not on the benchmark chart in tab 23.

The Migration Trap and How to Avoid It

The fear underneath the 47 tabs is usually "what if we pick wrong and have to migrate?" Fair. The fix is to make migration cheap by construction: store your source documents and embeddings in object storage, with the database holding references rather than the only copy, and hide the index behind a thin internal API, fifty lines with functions like search(query, filters) and upsert(chunk).

With those two moves, swapping pgvector for Qdrant later is a week of re-indexing from storage, not a quarter of archaeology. The decision stops being a bet-the-company moment, which is what it should have been all along. And get your guardrails and evaluation habits in place early, because a faster index just retrieves the wrong chunk more confidently when nobody's measuring.

So: start on Postgres, answer the four questions honestly, and let real numbers, not tab 23, tell you when it's time to graduate. If you're still weighing bigger architecture questions like fine-tuning versus RAG for the same project, settle that first, since it changes what the index even needs to do. The best vector database is the one you never think about again.

Frequently Asked Questions

Is pgvector good enough for production RAG?

Yes, for the large majority of business RAG. It handles millions of vectors with sub-100-millisecond queries, and your filters stay as plain SQL next to your transactional data. It also removes an entire system from your ops burden. Only real scale or latency triggers justify moving.

How many vectors can Postgres handle before I need a dedicated database?

A reasonable rule of thumb is that pgvector stays comfortable into the low millions of vectors, roughly 5 million or more depending on hardware and query patterns. Beyond tens of millions, or when indexing time and filtered queries start degrading, dedicated engines pull ahead. Measure your actual workload rather than planning for a hypothetical one.

What's the actual difference between Qdrant, Weaviate, and Pinecone?

Shape, not magic. Qdrant is lean and self-hostable with strong filtering; Weaviate is feature-rich with hybrid search at the cost of operational weight; Pinecone is fully managed, trading money for zero ops. Pick based on who runs it and what constraints you actually have.

Do I need a vector database for a few thousand documents?

Almost certainly not a dedicated one. A few thousand documents is tens of thousands of chunks, which pgvector handles trivially, and even brute-force search can work at that size. Spend your effort on chunking quality and evaluation instead; those determine answer quality far more than the index does.

Want the full picture? Read the complete guide to forward deployment engineers.

Read the Guide