Do I need pgvector or a dedicated vector database?

Not necessarily. It depends on your scale, latency needs, update pattern, and how much operational complexity you want to take on.

Short answer

• Use pgvector if you already use Postgres, your dataset is modest to medium, and you want the simplest stack.
• Use a dedicated vector database if you need very high scale, very low latency at large recall, heavy write/update throughput, advanced vector-specific features, or you’re building a retrieval system as a core product.

When pgvector is enough

pgvector is a good fit when:

• You already have Postgres in production
• You want one database instead of two
• You have up to millions of vectors or a moderate retrieval workload
• You need filters + vector search together
• You want easier backups, migrations, transactions, and joins
• You’re prototyping or building an MVP

Typical examples:

• Product search with embeddings
• RAG over internal docs
• Semantic search with metadata filters
• Recommendation prototypes

When a dedicated vector DB is better

Consider a vector database when:

• You have tens/hundreds of millions+ vectors
• You need consistently low latency under high QPS
• You need frequent embedding updates or deletes at scale
• You want vector-native features like:
  • hybrid search tuning
  • advanced ANN indexing options
  • replication/sharding built for vectors
  • per-tenant isolation at scale
• You don’t want your main OLTP database to also handle vector workloads

Examples:

• Large-scale consumer search
• Real-time retrieval for many users
• Multi-tenant SaaS with large corpora per tenant
• Retrieval as a primary product feature

Tradeoff summary

pgvector

Pros

• Simpler architecture
• Uses familiar SQL
• Easy to join with app data
• Great for filters and transactions
• Lower ops burden

Cons

• Not as specialized for very large-scale vector workloads
• Can become slower/costlier as volume and concurrency grow
• Indexing and tuning matter a lot at scale

Dedicated vector DB

Pros

• Built specifically for similarity search
• Better scaling paths for large vector workloads
• Often better performance at high QPS and large corpora
• More vector-search-specific features

Cons

• Another system to run and monitor
• Data duplication if your source of truth is Postgres
• More complexity in syncing metadata and vectors

Practical recommendation

A common path is:

1. Start with pgvector
2. Measure:
   • recall
   • p95 latency
   • write/update cost
   • operational pain
3. Move to a dedicated vector DB only if you hit limits

This is usually the lowest-risk choice unless you already know you’re at large scale.

Rule of thumb

If you can describe your use case as:

• “search over embeddings, plus metadata filtering, for a reasonably sized dataset” then pgvector is probably enough.

If you can describe it as:

• “vector search is a core, high-throughput, large-scale production workload” then a dedicated vector DB is worth evaluating.

If you want, I can help you choose based on your:

• vector count
• QPS
• latency target
• update rate
• existing stack