Sometime this week, an AWS engineer shipped a feature that used to require its own company. DynamoDB, the operational database behind a huge slice of production apps, now handles native vector search. You create the index, embed your documents, and run nearest-neighbor queries. It all happens inside a database you already pay for.
For five years, the standard first step in any RAG build was identical. Pick a standalone vector database. Pinecone, Weaviate, Milvus, Qdrant, take your pick. The vector store anchored every architecture diagram. Almost nobody asked whether it needed to be a separate system at all.
That assumption just took a hit. Oracle is pitching 26ai, an AI-native database with retrieval built in. MariaDB has been buying up vector and search technology. PostgreSQL has quietly run pgvector in production at thousands of companies that never installed a dedicated store. Vector search is becoming a checkbox on a database feature list rather than a purchase decision.
For a five-person startup choosing an architecture this month, the timing is awkward. Almost every RAG tutorial on the internet still starts with “sign up for a vector database.”
So the question making the rounds on engineering Slack channels is fair. Is the standalone vector database dead?
No. But the default is. “Always spin up a dedicated vector store” stopped being the right opening move. Your main database can answer nearest-neighbor queries on its own now. What replaced it is a genuine tradeoff, and most teams are still making it on vibes.
Here’s the breakdown: what changed this week, the four things a standalone vector database still does better, the cases where native vector search wins outright, and five questions to run before your next architecture review. Real numbers where they exist. As little “it depends” as possible.
What Just Changed: Vector Search Became a Database Feature
AWS was not first. Aurora, OpenSearch, MemoryDB, and Neptune all added vector capabilities over the past two years. Each one got a polite nod. DynamoDB is different. The difference matters.
DynamoDB is the system of record. It holds the orders, the user profiles, the line items. When vector search lives in that same database, the index stops being a separate thing you have to keep in sync with reality. The delete problem, the one that quietly rots most production RAG systems, shrinks. There is no second copy to forget about.
Oracle’s 26ai push and MariaDB’s buying spree point the same direction. Every major database vendor now believes vector search belongs inside the product, not next to it.
The money explains the urgency. Menlo Ventures, in its State of Generative AI in the Enterprise report, measured enterprise GenAI spend jumping from $11.5B to $37B in a single year. A 3.2x increase. Mordor Intelligence and Grand View Research both put the RAG market at roughly $2.0 to $2.3B today. Both see it reaching $10B to $11B by 2030. That’s around 49% growth per year.
When a category grows that fast, vendors stop treating it as a niche add-on. Vector search is following the path full-text search took before it: a specialized product category in the 1990s, a database feature by the 2000s.
There’s an irony in this for RAG teams. The standalone vector database was the most visible part of the stack. It got the vendor pitches and the architecture debates. It was never the part that decided whether your system worked. More on that later.
Four Things a Standalone Vector Database Still Does Better
Native vector search inside the database you already run is convenient. It also comes with real tradeoffs, and four of them are hard to ignore.
Scale, and the index quality that comes with it
Dedicated stores exist because approximate nearest-neighbor search is really hard at scale. A few million 768-dimension vectors fit in a couple of gigabytes, and nearly anything can serve that. A billion vectors with millisecond latency targets is a different sport. That game is played with tuned HNSW parameters, quantization, careful sharding, and GPU-backed indexes.
Operational databases can serve the first workload today. The second is where a standalone vector database earns its invoice, and where the “just consolidate” argument falls apart.
Retrieval features beyond pure vector search
Hybrid search means BM25 keyword matching combined with dense vector retrieval. It’s what fixes domain jargon and acronym failures, and it’s hard to bolt onto a general-purpose database. A standalone vector database ships it out of the box, along with reranking hooks, sparse embedding support, and multi-vector handling. If your retrieval quality plan depends on hybrid search plus a reranker, the dedicated vendors are further along.
Filter-heavy queries at high query volume
Enterprise RAG queries almost never arrive bare. They carry tenant filters, permission filters, date ranges. Standalone stores handle filtered ANN search with pre-filtering that keeps recall high while the filters get aggressive. General-purpose databases usually post-filter, which works until it doesn’t. The failure mode is a query that returns three results and a confident hallucination.
Tooling that assumes vectors are the job
A standalone vector database comes with an operational layer: backups tuned for large indexes, index rebuilds that don’t take the store down, replication lag you can reason about in vector terms, namespace-level multi-tenancy. None of this is impossible with the database you already run. You’ll just be building it yourself instead of inheriting it.
Where Native Vector Search Wins Outright
The case for staying inside your existing database is strongest in the situations most small teams are already in.
You have fewer engineers than systems
A team of five running Postgres, Redis, and a standalone vector database has three pager rotations and one production gap problem. Consolidating retrieval into the database you already operate deletes an entire stateful system. It’s gone from your on-call schedule, your backup policy, and your upgrade path. For a 10-person company, that trade beats most performance arguments.
Your data changes constantly
If documents get edited, deleted, and re-permissioned all day, a separate index is a drift generator. The vector index that quietly keeps serving deleted documents is one of the most common production failures we cover. It happens because the source of truth and the index are two systems with two lifecycles. Same-database indexing makes drift structurally hard instead of operationally optional.
Access control that holds up
Most permission-aware retrieval failures happen for one reason. Access control lives in one system, retrieval in another, and whatever sits between them can’t reconcile the two. When both live in the same database, row-level security can apply to vector queries too. That’s the difference between “we filter after retrieval, mostly” and a guarantee your auditors will accept.
The cost math at modest scale
Ten million vectors at 768 dimensions is a few gigabytes of raw storage. Running a separate vector tier for that is paying rent on a problem you don’t have yet.
Five Questions to Run Before You Pick
These are rules of thumb, collected from watching these builds go both ways. They are starting points, not verdicts.
-
How many vectors will you end up holding? Under about ten million, native search in your existing database is a safe default. Over one hundred million with real query volume, the dedicated stores pull ahead. Between those numbers, benchmark with your own data. Index behavior varies wildly by dimension count and filter load.
-
How filter-heavy are your queries? If most queries carry tenant or permission filters, and in enterprise they will, weigh the same-database option heavily. Consistency between the filter source and the index is worth real recall points.
-
What’s your sync story? Documents that change hourly plus a separate vector index is a drift incident waiting for a date. Same-database indexing removes that failure class entirely.
-
Who’s on call for it? A standalone vector database is a stateful system with its own failure modes, upgrade path, and backup needs. If nobody on your team has run one in production, budget for the learning curve, not just the license.
-
What does your data residency require? Sovereignty mandates change the math. India’s Yotta partnered with IntelliDB around sovereign AI and data residency, and the pattern is repeating across Europe. If your data must stay in a specific jurisdiction, the database you already run there is the path of least resistance.
The teams that get burned are the ones that pick either side on principle and skip the benchmark.
The Store Matters Less Than You Think
Here’s the part that should reframe the whole debate. Ask experienced RAG engineers where the highest-ROI improvement lives. The answer is the same across r/Rag, r/LLMDevs, and Hacker News threads: parsing and data quality. Not the vector database, and not even the model. What goes into the index beats what serves the index.
Buyer priorities have moved the same way. The CTO consensus on production RAG has shifted past raw retrieval performance. The question now is whether the system is auditable, secure, and maintainable enough to hand to a compliance team.
That shift argues for architectural humility. Keep the storage layer thin. LlamaIndex and LangChain both expose vector store adapters. Spring AI 2.0 unifies the Java side of the stack. Model Context Protocol adoption is up around 8,000% this year by Nevermined and CData’s count. Connectors are standardizing fast enough that your standalone vector database is a swappable decision, not a marriage.
Pick based on this quarter’s constraints. Benchmark when scale changes. And if a dedicated store is working for you, don’t migrate out of principle. The teams that get hurt are the ones that treat their vector store as an identity instead of a component.
The Verdict, and What to Do Next
So, is the standalone vector database dead? No. Pinecone, Milvus, Qdrant, and Weaviate still do things no operational database can match at scale. Pretending otherwise gets expensive at the hundred-million-vector mark. What died this week is the assumption. DynamoDB doing native vector search, Oracle’s 26ai push, MariaDB’s shopping spree. Together they ended the era when “which vector database?” was question one by default.
The new question one is whether you need a separate retrieval system at all. For most teams under ten million vectors running filter-heavy enterprise queries, the answer is increasingly no. For everyone else, the five questions above, answered honestly, will beat any vendor deck.
Two threads worth pulling next. If retrieval latency is your constraint, read why vector search is moving to silicon. And if you’ve ever caught your index serving deleted documents, our piece on the seven warning signs of index rot will sting in the right way.
If you’re building a RAG product and the documentation isn’t keeping up with the architecture, that’s the gap we close at Rag About It. Technical writing for teams shipping AI systems, from implementation guides to API references. Subscribe for the weekly rundown, or tell us what stack you’re running and we’ll break it down.
