pgvector vs a vector database: an honest comparison

Your team shipped retrieval — support-answer search, contract lookup, a product copilot — on Postgres with pgvector because it was an afternoon's work and no new vendor. Six months later someone asks whether you should move to Qdrant, Weaviate or Pinecone, and nobody can answer with numbers. This is a build-versus-buy call that founders and CTOs at Indian B2B companies make on vibes far more often than on evidence. Here is the framing we use with clients.

What pgvector actually gives you

pgvector gives you approximate nearest-neighbour search inside the Postgres you already run, so you add a feature without adding a system. You enable the extension, add a vector column and an HNSW index, and embeddings sit next to the rows they describe. That adjacency is the underrated part: you can join vectors to tickets, orders or invoices and filter with ordinary SQL. Backups, roles, migrations and monitoring are things your team already knows how to do. Below roughly a million chunks, on an instance with enough RAM to hold the index, it is genuinely hard to beat on effort per unit of value.

Where pgvector starts to hurt

It hurts when the HNSW index stops fitting in memory, or when vector writes start competing with transactional traffic on the same primary. As a rough guide, an HNSW index over one million 1536-dimension vectors is typically a few gigabytes; at ten million you are into tens of gigabytes that must stay resident, or recall and latency fall away sharply. Filtered search is the second weak spot — Postgres can plan a filter-first scan that quietly returns fewer rows than you asked for, so you over-fetch and re-rank in application code. And every reindex is a database operation on your primary, not a background job on a search cluster.

What a dedicated vector database actually buys you

A dedicated vector database buys you an index designed for vector workloads, independent scaling and stronger filtered search, at the price of a second system to run. Products such as Qdrant, Weaviate and Milvus separate compute from storage so replicas can be added without touching your primary, handle metadata filters natively, and support hybrid dense-plus-sparse search with recall as a first-class metric. What they do not do is remove operational work: you gain another backup policy, another auth model, another service that pages someone at 2am. The cost structure also shifts from a fixed database bill to per-vector or per-query pricing that grows with your success. If you are weighing that against building the retrieval layer in-house, map the moving parts first — our architecture notes cover how we usually split ingestion, embedding and serving.

A worked example: 400,000 chunks versus 8 million

The crossover usually shows up in the arithmetic long before it shows up in production. Take an internal document search tool: 400,000 chunks at 1536 dimensions in float32 is about 2.4 GB of raw vectors, call it 3-4 GB of index resident in RAM once HNSW overhead is counted. A 4 GB managed Postgres instance handles that comfortably, and the incremental cost is near zero because the database already exists for the application. Now grow the same product for two years: eight million chunks, plus per-tenant filtering for 60 customers. That is roughly 49 GB of raw vectors, an index that no longer fits a sensible instance size, and a primary that is also serving CRM reads. At that point a dedicated cluster typically costs less per month than the vertical scaling, and far less than a bad Friday.

How to decide in a week

You can settle this in a week by testing your own queries against your own corpus, not by reading vendor benchmarks. Build an evaluation set of 50-100 real user questions with the correct chunks labelled, then measure recall@10 and p95 latency on both options. The heuristics that usually survive contact with the numbers:

• Under about a million vectors, one tenant, p95 budget above 50-80ms: stay on Postgres and spend the saved effort on the eval set.
• Heavy metadata filters or strict per-tenant isolation: benchmark filtered recall specifically, because that is where naive pgvector setups fail silently.
• Above roughly ten million vectors, or an index larger than your available RAM: plan the move, and budget typically 2-6 weeks including dual-write and backfill.
• No ops capacity on the team: choose a managed service rather than self-hosted Milvus, and treat it as a vendor dependency from day one.

Either way, keep the embedding pipeline behind an interface so that switching stores is a config change and not a rewrite. Our AI engineering work leans on that pattern because it is the cheapest insurance available.

Where to start

Start with the evaluation set, not the vendor shortlist — a week of labelling real queries will tell you more than any comparison chart. At Maysan Labs we build retrieval features on both Postgres and dedicated vector stores, and the honest answer for most Indian B2B teams under five million vectors is to stay on Postgres for another year and revisit when the index outgrows the instance. If you want a second opinion before signing a vector database contract, that is usually a short conversation.