Choosing a Vector Database (You Probably Need Postgres)

Choosing a vector store feels like a significant architectural decision. For most teams it is less consequential than it appears, and the usual mistake is adopting specialised infrastructure before there is a problem that requires it.

Start with the database you already run

If you are on PostgreSQL, pgvector is almost certainly where to begin. It is an extension, not a new system. It gives you vector similarity in the same database as your relational data, which means one backup strategy, one connection pool, one set of credentials, one thing to monitor — and, importantly, the ability to filter by ordinary SQL conditions in the same query as the similarity search.

That last point is underrated. Real queries are rarely pure similarity. They are "similar to this, belonging to this tenant, not archived, created in the last year". Doing that in one query against one system is much simpler than coordinating a vector store and a relational store.

At a few million vectors with sensible indexing, this is comfortable. Most products never exceed it.

When a dedicated store earns its place

• Scale beyond tens of millions of vectors, where purpose-built indexing and memory layout genuinely matter.
• Very high query throughput where you need to scale search independently of your transactional database.
• Frequent full re-indexing, which a dedicated system handles more gracefully.
• You do not run a database and do not want to. A managed vector service is a reasonable choice when the alternative is operating Postgres for the first time.

What actually differentiates them

Not recall quality — at comparable settings, the mainstream options perform similarly. The real differences are operational:

Metadata filtering. Whether filters are applied during search or after it. Post-filtering can return far fewer results than requested when filters are selective, which is a nasty surprise in production.

Index build and update behaviour. How long a rebuild takes, and whether search degrades while it happens.

Hybrid search. Whether keyword and vector search are available in one system, or whether you are assembling that yourself.

Cost shape. Priced by stored vectors, by queries, or by provisioned memory — these produce very different bills at the same workload.

The decision that matters more

Your embedding model constrains quality far more than your storage engine. The dimensionality, the domain fit, and whether it handles your language and jargon will move results more than any index choice.

And changing embedding model means re-embedding everything. Design for that: store the model and version alongside each vector, and build the re-index path before you need it, because you will need it.

A reasonable default

Postgres with pgvector, hybrid search with a keyword index, reranking over the candidates. Measure. Move to specialised infrastructure when you have a measurement that says you must — not when a comparison table says you might.