← All articles
pgvector vs dedicated vector DBs: for Italian cases, is Postgres enough?

pgvector vs dedicated vector DBs: for Italian cases, is Postgres enough?

2 min read

Pinecone, Qdrant, Weaviate. Or just pgvector. The real thresholds where dedicated databases win.

Since RAG entered our projects, "which vector DB do we pick?" is a recurring question. Short answer: pgvector for most Italian SME cases.

The thresholds

Picking a dedicated vector DB (Pinecone, Qdrant, Weaviate) requires at least one of these:

  • Huge volumes: more than 10 million vectors. Below, pgvector with HNSW handles fine.
  • Very complex filters: metadata + similarity combinations needing specialised indexes.
  • Frequent updates: re-embedding parts of the corpus hourly. pgvector copes but with higher latency.

Otherwise

pgvector wins on:

  • Ops: one database to manage, back up, monitor.
  • Cost: zero additional infra.
  • Native joins: combining similarity + classic SQL filters is trivial.
  • Zero lock-in: it's Postgres.

HNSW vs IVFFlat in pgvector

pgvector 0.5+ supports HNSW. Faster than IVFFlat on queries, more memory and build time. On our 60k-vector case: 1.8ms (HNSW) vs 6.4ms (IVFFlat), build 14s vs 2s. For stable datasets HNSW wins; for frequently changing datasets, IVFFlat is more pragmatic.

Field lessons

Across 6 RAG projects with Italian clients, 5 sit on pgvector and 1 on Qdrant (complex metadata filters). The nearly always Postgres rule holds even 12 months on. Don't go dedicated early — solve the problem first, infra later.