pgvector or a dedicated vector database

The argument for boring

Adding a vector database adds a second system of record. Your documents live in Postgres; their embeddings live somewhere else; and between them sits a synchronisation process that is now part of your correctness story.

That process fails in the worst possible way: silently, and in the direction of confident wrong answers. A document is deleted or corrected, the delete does not propagate, and the assistant cites a paragraph that no longer exists. Nothing errors. No dashboard turns red.

With pgvector, the chunk row and the vector update in the same transaction as the source. The failure mode disappears rather than being monitored.

What you should actually tune

Most disappointing pgvector benchmarks are untuned defaults. Three settings carry the outcome.

• Index type: HNSW over IVFFlat for most read-heavy RAG workloads - better recall at a given latency, at the cost of build time and memory
• hnsw.ef_search: the recall/latency dial at query time; raise it until recall plateaus, then stop
• Dimensionality: many embedding models support shortened outputs with minimal quality loss - halving dimensions roughly halves index size and speeds every search
• Filtering strategy: filter on indexed metadata columns alongside the vector search rather than over-fetching and filtering in application code

The signals that justify moving

Not corpus size on its own. Specific, measured symptoms.

Index rebuild time interfering with your maintenance window. Vector search competing for buffer cache with your transactional workload in a way you can see in query plans. p95 search latency exceeding budget after the tuning above. Write throughput that turns index maintenance into a bottleneck.

If none of those are true, moving to a dedicated store is adding an operational dependency to solve a problem you do not have.

The hybrid position

There is a middle option teams overlook: keep the source of truth and metadata in Postgres, and treat any external index as a derived, disposable cache that can be rebuilt from Postgres at any time.

That preserves the property that matters - one system owns the truth - while letting you use a specialised index for search. Rebuild is a script, not an incident.