Vector Databases: Do You Actually Need One?

The moment people add embeddings to an app, they reach for a dedicated vector database. Sometimes that's right. Often it's a new piece of infrastructure to run, monitor and pay for, solving a problem you don't have yet.

What these things actually do

A vector database stores embeddings and finds the nearest ones to a query fast, using approximate nearest-neighbour indexes. That's the core feature. Everything else — filtering, hybrid search, sharding — is convenience and scale on top of that one trick.

pgvector is probably enough

If you already run Postgres, the `pgvector` extension gives you vector search right next to your relational data. No extra service, no data sync, and you get to filter by your normal columns in the same query. For the low millions of vectors, this is boringly sufficient — and boring is a compliment in production.

When to graduate

Reach for a dedicated vector store when you genuinely outgrow that: tens of millions of vectors, strict low-latency requirements at scale, complex metadata filtering, or first-class hybrid search you don't want to build yourself. Upgrade because a metric forced you to, not because a tutorial did.