Request Consultation
Blogs

Vector Databases: When You Actually Need One

Vector DBs were the hot category of 2023. Most teams that adopted one did not need it. Here is when you genuinely do.

Mar 22, 2026 4 min

The vector database hype outran the actual need. The math on when you really need one is straightforward.

The 2023 LLM gold rush created a vector database boom. Pinecone, Weaviate, Qdrant, Chroma, Milvus, Vespa, plus dozens of startups. By 2026 most of those teams have learned that Postgres with pgvector handles 90% of the workload. Here is when you actually need a dedicated vector database.

What pgvector handles

  • Up to ~10 million vectors with HNSW indexing.
  • Sub-50ms queries on warm data with default settings.
  • Hybrid search (vector + keyword + filters) using SQL.
  • The same Postgres your application is already on, with the same backups, the same access control.

For most RAG implementations, internal search, and recommendation systems under 10M items, pgvector is enough.

When you actually need a dedicated vector DB

  • You have 100M+ vectors and Postgres planning starts taking longer than the query.
  • You need sub-10ms p99 latency with high concurrency.
  • You need multi-tenant isolation at the index level (different customers, different shards).
  • You are doing semantic-search-heavy work where index tuning is your full-time job.

The practical comparison

  • pgvector: 90% of use cases. Zero new operational burden.
  • Qdrant: open-source, Rust-based, strong performance, growing ecosystem.
  • Weaviate: open-source, GraphQL API, strong hybrid-search story.
  • Pinecone: managed, lowest engineering effort, highest cost. Defensible if you do not have a DBA.
  • Vespa: open-source, the workhorse of large search systems (Yahoo, etc.). Steeper learning curve.

The architecture pattern

Even when you adopt a dedicated vector DB, keep the source of truth in Postgres. Your customer table, your document table, your transaction log — all in Postgres. The vector index is a derived view that gets rebuilt from the source. This way you can swap vector DBs later without losing data.

Our default

For client RAG and search projects, we start with pgvector. We migrate to a dedicated vector DB only when measurement shows pgvector is the bottleneck. About 1 in 5 projects ever crosses that threshold.