Almost every team that asks us which vector database to use has already read three benchmark posts and is comparing queries per second. That is the wrong starting point, and it is the reason so many of these decisions get reversed six months later.
The four options people shortlist in India are pgvector, Qdrant, Weaviate and Pinecone. They all do the same core job competently. What separates them is operational: who runs the thing, how it behaves when you filter, and what happens when your data and your team change shape. This post is about those differences.
They are all solving the same narrow problem
A vector database stores high dimensional numbers produced by an embedding model and finds the stored vectors closest to a query vector. Beyond a few thousand items, comparing against every stored vector becomes too slow, so these systems use approximate nearest neighbour indexes. HNSW, a graph based index, is the one all four offer and the one most production systems end up on.
Approximate means what it says. You trade a small amount of recall for a large amount of speed, and every one of these systems exposes knobs to move that trade. Two systems configured differently will produce different results on the same data, which is exactly why benchmark comparisons across products are so often misleading.
If you are still deciding whether you need retrieval at all, that question comes first and we covered it in choosing between fine-tuning and RAG.
pgvector: the answer more often than people expect
pgvector is a PostgreSQL extension. It adds a vector column type and distance operators, and it supports both exact search and approximate indexes including HNSW. Your embeddings sit in a table next to your ordinary relational data.
That last sentence is the whole argument. If your application already runs on PostgreSQL, choosing pgvector means no new service to deploy, no second system to back up, no separate access control model, no extra network hop, and no synchronisation problem between your source of truth and your index. You write the embedding in the same transaction that writes the record. When the record is deleted, the vector goes with it.
Teams underrate how much work the alternative creates. Running a separate vector store means you now own a pipeline that keeps two systems consistent, and that pipeline will drift. Stale vectors pointing at deleted products is a bug class you simply do not have with pgvector.
Where it gets uncomfortable is scale and index maintenance. Building an HNSW index is memory hungry, and on a large table it is a real operational event rather than a background detail. Very high write throughput against an indexed vector column is not where PostgreSQL is happiest. And if your retrieval traffic is heavy enough to compete with your transactional traffic for the same database resources, you have a noisy neighbour problem on your most important system.
We used pgvector for the approach in hybrid search with PostgreSQL, which is still the setup we reach for first.
Qdrant: the usual next step
Qdrant is a purpose built vector database written in Rust, available open source and as a managed service. It is the one we most often move teams to when PostgreSQL starts creaking.
Its strongest practical advantage is filtering. Real queries are rarely pure similarity. They are similarity within a category, within a price band, for one tenant, for documents the user is allowed to see. Naive implementations do this badly: they either filter after retrieving, which quietly returns fewer results than you asked for, or they filter before, which defeats the index. Qdrant was designed with filtered search as a first class concern rather than an afterthought, and it shows when your filters are selective.
It also offers quantization, which reduces the memory each vector occupies at some cost to precision. On a large collection this is the difference between a machine you can afford and one you cannot.
The cost is that it is another service. Another deployment, another thing to monitor, another backup story, another place for your data to be inconsistent with your database.
Weaviate: pick it for the shape of your search, not the vectors
Weaviate is also open source and self-hostable, with a managed option. The reason to choose it is usually not raw vector performance. It is that Weaviate treats hybrid search, combining keyword matching with vector similarity, as a built-in rather than something you assemble.
That matters more than it sounds. Pure vector search is weak at exact tokens: part numbers, SKUs, model names, drug names, names of people. A buyer searching for a specific product code wants that exact match, and an embedding model will happily return twelve things that are semantically nearby and useless. For catalogue search this is the difference between a feature that works and one that gets switched off. We went into that failure mode in AI product search for ecommerce.
Weaviate also has a module system that can generate embeddings for you at write time. Convenient at the start, and a coupling you should be deliberate about, because changing embedding model later is a re-indexing project either way.
Pinecone: paying so you never think about it
Pinecone is fully managed and proprietary. You cannot run it yourself. That is the point of it.
Choose Pinecone when you have no infrastructure team, when nobody on the project wants to be paged about index memory, and when the cost of your engineers’ attention is higher than the subscription. For a small product team shipping quickly, that is a defensible trade and we have recommended it.
Be clear about what you are accepting. Your embeddings live with a vendor, your costs scale with usage in a way you do not fully control, and you cannot inspect or tune the internals when something behaves oddly. For an Indian company with data residency expectations from its own customers, that last point is sometimes the whole conversation, and it is worth having before you build rather than after.
The things that actually decide it
In practice four questions settle this, and none of them is throughput.
- How many vectors, realistically, in eighteen months. Not your ambition. Your content multiplied by your chunking strategy. A company website, a product catalogue and a few years of support tickets is a far smaller number than most teams assume.
- How complicated are your filters. If every query is scoped by tenant, permission or category, filtering behaviour matters more than index speed.
- How often does the data change. A corpus rebuilt nightly has completely different needs from one updated on every customer action.
- Who maintains this in a year. If the honest answer is one developer who also does everything else, every argument points towards fewer moving parts.
Our rule of thumb, and it is ours rather than an industry standard: if you are already on PostgreSQL and your corpus is in the hundreds of thousands of vectors rather than the tens of millions, use pgvector and spend the saved effort on chunking and evaluation, which is where retrieval quality actually comes from.
What is a waste of time
Comparing published benchmarks across products. They are run on different hardware, different datasets, different recall targets and usually by someone with an interest in the result. They cannot tell you how a system behaves on your data with your filters.
Optimising the index before you can measure retrieval quality. If you have no evaluation set, you cannot tell whether a configuration change helped or hurt, and you will tune on vibes.
Treating the database choice as the hard part. It is not. Chunking, the embedding model, and whether you rerank results are what move answer quality. The store is plumbing, and plumbing is replaceable.
Migration is cheaper than the fear of it
The anxiety in this decision comes from believing it is permanent. It is not, provided you build with one boundary in place: keep retrieval behind an interface of your own rather than scattering vendor specific calls through your application.
Your source documents and the code that chunks them are the assets. Embeddings are derived data that you can regenerate. Moving stores means re-embedding and re-indexing, which costs compute time and an evening, not a rewrite. Teams that keep the raw text and the chunking logic under their own control move between these systems without drama. Teams that let the database own the pipeline do not.
The operational questions people ask too late
Four things rarely appear in the comparison and reliably appear in the second month.
Backups. If your vectors live in PostgreSQL they are inside your existing backup and restore procedure, tested or not. A separate vector store is a separate backup story that somebody has to own. Ask how a restore works before you need one, and note that for derived data the answer may reasonably be we re-embed from source, which is fine as long as it is a decision rather than a discovery.
Multi-tenancy. If you serve several clients or business units from one system, decide early whether tenants are separated by a filter, by a collection, or by a whole instance. Filtering is cheapest and puts the entire burden of data isolation on application code being correct every time. Separate collections cost more and fail safer. For anything where one client seeing another’s documents would be serious, pay the extra.
Index rebuilds. At some point you will re-embed or reconfigure, and the question is whether that can happen without downtime. Building a second index alongside the first and switching once it is ready is the pattern that works. Check your chosen system makes that straightforward rather than assuming it does.
Who gets paged. A retrieval system that is down looks to users like a product that is broken. If nobody is monitoring it, you will learn about outages from a customer.
What actually changes at scale
The thresholds people worry about are rarely the ones that bite.
Memory is usually the first real constraint, not query speed. Graph-based indexes are held in memory, and the requirement grows with your vector count and dimensions. The point where your index no longer fits comfortably on one machine is the point where the decision changes, and that is an arithmetic question you can answer today rather than a mystery.
Write throughput is the second. Systems optimised for search handle steady ingestion well and bulk reloads less gracefully. If your corpus is rebuilt nightly rather than updated continuously, test that specific pattern rather than the steady-state one.
Filter selectivity is the third, and the least expected. A query filtered down to a small slice of a large collection behaves very differently from an unfiltered one, and some systems degrade sharply in exactly that case. If your queries are always scoped to a tenant or a category, that is the case to benchmark, not the general one.
None of this is a reason to over-provision early. It is a reason to know which number you are watching, so the move happens when the data says so rather than when somebody reads an article.
A sensible sequence
- Build an evaluation set first. Thirty to fifty real questions with the documents that should be retrieved. Without this you are guessing.
- Start with pgvector if you already run PostgreSQL. Get the whole path working end to end.
- Fix chunking and add reranking before you touch the database. This is where most of the quality is.
- Measure where it actually hurts. Index build time, filtered query latency, memory, consistency bugs.
- Move only when a specific measured pain points at a specific capability. Filtering pushes you to Qdrant, keyword and vector together push you to Weaviate, no operations capacity pushes you to Pinecone.
The teams that get this right are rarely the ones that chose the best database. They are the ones that kept the decision reversible and spent their attention on retrieval quality instead.
If you want help sizing this for your own corpus, our AI development work covers exactly this, and you can get in touch to talk it through.