Ask ten engineers how to build retrieval-augmented generation and nine will tell you to stand up a managed vector database. Pinecone, Weaviate Cloud, Qdrant Cloud, a hosted Milvus — it has become the default reflex. For most agency and marketing workloads in 2026, that reflex is now the most expensive and least necessary layer of the stack.
Three things changed this year: embedded vector databases that run inside your application process, a far more mature pgvector ecosystem, and benchmark data showing the performance gap between managed and self-hosted engines is narrower than the sales decks suggest.
The Managed Vector Database Default
The pitch is easy to understand. Vector search is a specialized workload, so use a specialized database and let someone else run it. That was reasonable back when pgvector was slow and no alternative existed.
The bill is less reasonable. A managed vector store is another service to provision, secure, monitor, back up, and pay for — usually billed by the pod or by the gigabyte of vectors stored. It is also a second copy of data that already lives in your primary database, which means every content update now has an ingestion job attached to it. And that ingestion job is where retrieval quietly breaks.
What Changed in 2026
Alibaba open-sourced Zvec, an embedded vector database that brings SQLite-like simplicity and high-performance on-device RAG to edge and application-embedded use cases. The framing is the point: a vector index that ships as a library, not a server.
Meanwhile the Postgres route stopped being a compromise. pgvector and pgvectorscale now handle the filtering, hybrid search, and index types that used to force teams onto a dedicated engine. If your content already lives in Postgres — and for most marketing systems it does — the vector index can sit next to it. One source of truth, one backup, one permission model.
The performance argument weakened too. AIMultiple benchmarked seven open-source vector engines for RAG head to head, and a practical Milvus walkthrough shows how little code a working pipeline actually needs. Nobody is benchmarking their way to a 100x advantage anymore. Oracle is even out arguing that AI belongs where the data already is — the vendors are converging on the same conclusion.
The Only Question That Matters: Scale Threshold
Managed vector databases are not wrong. They are just sold to the wrong customers. The honest decision rule is about total vectors, query volume, and operational headcount — not vibes.
As a working rule of thumb: if you are under roughly ten million vectors, serving modest query-per-second traffic, with data that already lives in a relational database, an embedded engine or pgvector will be cheaper, simpler, and fast enough. Above that — hundreds of millions of vectors, high QPS, heavy multi-tenant isolation, or a team with no bandwidth to tune indexes — a managed service earns its invoice.
Most agency RAG builds — a knowledge base of client documentation, a few hundred thousand chunks, dozens of queries a minute — live nowhere near that line. If you are still choosing, the tradeoffs are laid out in our guide to choosing a vector database for RAG.
The Hidden Cost Is the Second Data Copy
Every additional managed service adds three ongoing expenses: the subscription, the maintenance, and the failure surface. For a small team, the third is the real killer. A managed vector store means content changes must be chunked, embedded, and upserted into a system that can silently fall out of sync with the source of truth. When retrieval goes wrong — and it will — you have two databases to inspect instead of one.
Consolidating onto Postgres does not remove that work entirely, but it removes an entire class of drift, because the index is transactional with the data.
A Simpler RAG Data Architecture
The 2026 stack looks like this:
- Store and index in Postgres with pgvector, or pgvectorscale once indexes grow large. Your documents, metadata, and embeddings share one database.
- Add hybrid search. Keyword plus vector retrieval beats vector-only on real queries. That is a retrieval-quality decision, not an infrastructure one.
- Use an embedded engine like Zvec when the workload runs on-device or in-process and cannot afford a network hop.
- Reserve managed vector databases for the scale tier where self-hosting genuinely stops being an option.
The engine is no longer your bottleneck. Data quality, chunking, and retrieval strategy are — which is why the retrieval failures teams chase are almost always pipeline problems, not database problems.
What to Do This Week
- Count your vectors and your peak queries per second. You probably know one number and have never measured the other.
- Benchmark on your own data, not a vendor’s demo set.
- If the numbers say you are small, migrate to pgvector and cancel the managed plan. Put the savings into content quality, where retrieval actually improves.
Simpler infrastructure is not a downgrade. It is one fewer thing to break — and one fewer bill you have to justify.