You probably don't need a vector database
The AI wave pushed everyone toward a dedicated vector database. For most apps, Postgres with pgvector does the job - one fewer system to run, secure, and sync.
4 min read
Before you add a dedicated vector database to your stack, check whether the database you already run does the job - because for most apps, it does. The AI wave sent a lot of teams shopping for a specialized vector database to power search and RAG. But Postgres with the pgvector extension now handles vector similarity search well into the low millions of vectors, right alongside your application data. Reaching for a separate system by default means one more thing to run, secure, back up, and keep in sync - usually for a scale you won't hit for a long time, if ever.
Why this matters now
pgvector grew up. On a single Postgres instance with an HNSW index, it delivers roughly 5,000-15,000 queries per second for typical embeddings, and it "handles 2M vectors without special tuning" - which covers the vast majority of real RAG and semantic-search workloads (benchmark roundup). More importantly, the vectors live next to your application data, so you get SQL filtering and vector search in a single query, inside a single transaction.
That last point is the one teams underestimate. pgvector on Postgres is fully ACID-compliant - your embeddings and your relational data stay transactionally consistent - whereas purpose-built vector databases generally don't offer full ACID guarantees (2026 comparison). If your vectors need to stay in step with the rows they describe, that's a decisive advantage.
The real trade-off: one system or two
Adding a separate vector database isn't just adopting a tool - it's taking on a distributed-systems problem. Now you have two stores that must be kept in sync: every write has to land in both, and when they drift (they will), you own the reconciliation. You've also doubled the surface you have to secure, monitor, and back up. None of that is free, and for a corpus in the low millions, none of it buys you anything.
The unified approach removes the whole category of problem. One system, one backup, one security boundary, and a query that can say "find rows similar to this embedding where the user owns them and the status is active" in a single SQL statement.
When you genuinely do need a dedicated vector database
This is not a "Postgres for everything, always" argument - that would be as lazy as the reflex we're pushing back on. There's a real cutoff:
- Past the low millions of vectors. At 5M vectors,
pgvectorp95 latency climbs into the 80-140ms range, and dedicated systems pull ahead - one benchmark has a purpose-built store at ~4ms p50 (benchmarks). Beyond that you'll want an extension likepgvectorscaleor a dedicated database. - Corpora far larger than RAM, where you need disk-resident indexes and quantization built for scale.
- Vector search as your core product at very high QPS, where every millisecond of latency is a feature.
If that's you, use the specialized tool - it's the right call. The point is to make that decision on evidence, at the scale where it pays off, not as a reflex at the start.
The best architecture is the one with the fewest moving parts that still meets the requirement. Add the vector database when the numbers demand it - not because the blog posts said AI needs one.
Our opinion
This is the same principle as our SQL vs NoSQL piece - start with Postgres - applied to the AI era. Our strong view: defaulting to a separate vector database is premature optimization for a scale most products never reach, and it's paid for in real operational complexity from day one. Start with pgvector, measure your actual vector count and latency, and graduate to a dedicated system when - and only when - the numbers say so. You'll ship faster, run less infrastructure, and keep your data consistent by default. And if you do outgrow it, moving is a well-trodden path, not a trap.
How Ashvara helps
We build backends that stay simple on purpose - fewer systems, clearer data ownership, less to break at 3am. When a product needs semantic search or RAG, our default is to add it to the database you already run and only reach for specialized infrastructure when the scale is real. We'll size it honestly against your actual data, not a hypothetical.
If you're adding AI search to a product and wondering whether you need a whole new database for it, that's exactly the backend and API question we love. Talk to us - often the answer saves you a system.
Sources: pgvector performance benchmarks (Instaclustr); vector databases compared 2026 (Kalvium Labs); pgvector review 2026.