"Do we need a dedicated vector database, or can we just use Postgres?" comes up in nearly every project that involves semantic search or retrieval. The honest answer is that for a real share of production workloads, a dedicated vector database is unnecessary complexity, and for another real share, it's the right call from day one. The question is which situation you're actually in.
What a vector database actually does
Both a dedicated vector database and Postgres with the pgvector extension do the same core job: store embeddings and retrieve the nearest matches to a query embedding quickly. The difference is in how much scale, filtering complexity, and operational specialization that retrieval needs before it starts to matter.
When pgvector is genuinely the right call
- You already run Postgres. If your application data already lives there, adding pgvector means one fewer service to deploy, monitor, and pay for. Your embeddings can live next to the relational data they describe, which simplifies queries that would otherwise span two systems.
- Your scale is moderate. pgvector handles a genuinely large range of real-world workloads well, particularly with proper indexing (HNSW or IVFFlat depending on your access pattern). Most teams shipping a first production RAG system are well within what pgvector handles comfortably.
- Your filtering needs are the kind SQL is already good at. If retrieval needs to combine semantic similarity with structured filters (a date range, a tenant ID, a status field), pgvector lets you write that as ordinary SQL rather than learning a separate query language.
When a dedicated vector database earns its keep
- You're operating at a scale where retrieval latency and throughput become the bottleneck, such as many millions of vectors with high query volume. Here a database purpose-built for approximate nearest-neighbor search at scale can outperform a general-purpose relational database doing the same job as an add-on.
- You need retrieval features Postgres doesn't offer natively, like certain built-in hybrid search capabilities, multi-vector search, or indexing algorithms tuned for particular embedding distributions.
- Retrieval is genuinely the core of your product, not a supporting feature, and the operational specialization (managed scaling, purpose-built monitoring, a team that lives and breathes vector search) is worth the added infrastructure surface.
The actual decision framework
Start with pgvector if you already run Postgres and don't yet have concrete evidence that retrieval performance or feature needs have outgrown it. Migrate to a dedicated vector database when you have a specific, measured reason (a real latency problem at real scale, or a filtering need pgvector can't express well), not because it sounds more sophisticated or a blog post called it best practice.
How we approach this
We default to pgvector when a project already runs Postgres and current scale doesn't demand more, and move to a dedicated vector database when there's a specific, measured reason. It's an engineering decision grounded in your actual workload, not a default setting.