The vector DB you did not adopt.

If you picked pgvector eighteen months ago, some of your peers thought you were behind. Look at the bill now.

The hook

A CTO told me, quietly, over coffee last month, that eighteen months ago a peer called them "conservative" for putting vectors in Postgres instead of adopting a dedicated vector database. The word was not meant kindly. That same peer was on a podcast that year explaining why purpose-built vector infrastructure was the only serious choice for production AI. This year, the peer's company is considering a migration back to Postgres. Nobody is using the word conservative anymore.

वाळो जन मज ह्मणोत निंदाळी · Let People Scorn Me, I Will Not Let Go

वाळो जन मज ह्मणोत निंदाळी । परि हा वनमाळी न विसंबें ॥ १ ॥
सांडूनी लौकिक जालियें उदास । नाहीं भय आस जीवित्वाची ॥ २ ॥
नाइकें वचन बोलतां या लोकां । ह्मणे जालों तुका हरिरता ॥ ३ ॥
Choosing a direction that others do not yet see the value of will get you talked about. The talk is the cost of the choice, not a sign the choice was wrong.

What I keep seeing

The slide decks from 2024 were confident. "Postgres cannot scale vector search." "You need a purpose-built index." "HNSW in a general-purpose database is a toy." I sat through three of these talks. I nodded at two of them. I was wrong.

The CTOs who ignored the consensus and shipped pgvector are not being called visionary now, because nobody remembers who said what two years ago. They are simply running cheaper infrastructure with fewer moving parts. The ones who adopted Pinecone or Weaviate at scale are looking at invoices and migration plans.

The mechanics

A vector database is, mechanically, an ANN index plus a storage layer plus a metadata layer plus a query interface. HNSW is the dominant index type. pgvector, a Postgres extension, gives you HNSW inside your existing Postgres. Pinecone, Weaviate, Qdrant, and Milvus give you HNSW inside their own system.

For workloads under about 50 million vectors on a well-provisioned Postgres instance, the benchmarks are stark. pgvector's HNSW matches or beats Pinecone on query latency, wins clearly on cost, and wins substantially on filtered queries. That last point is the one that matters. In production, almost every vector query has a filter: this tenant, these permissions, this document type. Postgres can plan those filters together with the vector search using its normal query planner. Pinecone has to filter after retrieval or use metadata indexing, and both approaches degrade at scale.

Past 100 million vectors with sustained high QPS and multi-region requirements, dedicated vector databases pull ahead. That describes about 5% of the companies that adopted one.

Where Tuka comes in

The abhanga has the phrase "सांडूनी लौकिक जालियें उदास": having let go of what the neighbourhood counts as respectable, I have become at ease. The word "लौकिक" is what your professional peers say is respectable this quarter. Two years ago the laukik was "use a purpose-built vector database." Anyone who did not was called something with a slight edge to it. Conservative. Cautious. Behind.

Two years later, the laukik has moved on. The CTOs who took the reputational hit are, on a bill-of-materials basis, correct. They are not being celebrated. They are just paying less. The names faded. The savings did not.

What I would actually do

Every quarter, list the three most consensus opinions in your peer group about what to adopt. For each, ask: what is the strongest argument against this, and if I bet against consensus, what does it cost me if I am wrong versus what it saves if I am right? If the answers are asymmetric, small cost if wrong, large savings if right, you have found a place to bet against your peer group. You will get called names for a while. The names will fade before the savings do. This is not contrarianism as an aesthetic. It is forty-five minutes on a whiteboard with an expected-value calculation.

Chetan Dhandal