You Bought a Vector Database in 2024. Your Postgres Can Probably Do It Now.

Why Did Every AI Project End Up With Two Databases?

In 2023, if you wanted to build retrieval-augmented generation, the reference architecture arrived pre-assembled. Embeddings went into a dedicated vector database. Everything else stayed in whatever relational store the product already used. Nobody argued about it, because at the time the argument was genuinely settled: Postgres could store vectors, but the index implementations were young, the filtered-search behaviour was unreliable, and the specialists were shipping features monthly.

So teams did the sensible thing and added a second data store. Then they added a third for caching, and a queue to keep the two in sync, and a nightly reconciliation job for when the sync drifted. Three years later a lot of engineering organisations are running a retrieval stack whose topology was chosen by the state of open-source indexing in 2023 and has never been revisited.

What changed is not that vector databases got worse. They got better. What changed is that the gap they were built to fill mostly closed, while the costs of the extra store, operational, financial and now legal, stayed exactly where they were. pgvector shipped iterative index scans in 0.8.0, which fixed the overfiltering problem that made filtered vector search in Postgres genuinely bad. AWS measured up to 9x faster query processing on Aurora PostgreSQL with that release, and the improvement was largest exactly where Postgres used to be weakest: queries that combine a WHERE clause with a similarity search, which describes almost every real multi-tenant application.

This article is not an argument that vector databases are dead. That framing is lazy and the people running billion-vector workloads will tell you so. It is an argument that the default flipped, and that most teams have not re-run the decision since the inputs changed.

What Do the Benchmarks Actually Say About Postgres at Scale?

The most useful public numbers come from Tiger Data's benchmark of Postgres against Qdrant on 50 million Cohere embeddings at 768 dimensions. At 99% recall, Postgres with pgvector and pgvectorscale served 471.57 queries per second against Qdrant's 41.47, an 11.4x throughput advantage on a single node. At the more common 90% recall target, the figures were 1,589.79 QPS against 360.81.

Read the latency columns from the same run and the picture stops being one-sided. At 99% recall Qdrant returned a p95 of 36.73ms against Postgres at 60.42ms, and a p99 of 38.71ms against 74.60ms. Qdrant's tail is tighter and its index build took roughly 3.3 hours against 11.1 hours for pgvectorscale. If your product is a user-facing search box where the 99th percentile is the number that generates support tickets, that difference is not a rounding error, and if you rebuild indexes frequently the build time is an operational fact you will feel every week.

Treat the source with the scepticism it deserves. This is a vendor benchmarking its own extension, on hardware and index parameters it chose, which is true of essentially every vector benchmark published by anyone. The correct use of a number like 471 QPS is not to settle an argument. It is to establish that Postgres is now in the same performance class for a workload of this size, which is precisely what was not true when most teams made their original decision.

The other figure worth holding onto is the machine. That benchmark ran on a single server costing roughly $835 a month. A very large share of production RAG systems are working with a few million vectors, not fifty million, which means they are running a distributed specialist database to serve a workload that fits comfortably in the memory of one instance of a database they already operate.

What Does the Second Data Store Actually Cost to Run?

Engineering teams price databases by their invoice, which is the smallest and most visible part of what they cost. The real bill for a second data store is written in operational surface, and it is paid by the people who carry the pager.

Start with the boring inventory. A separate vector store is another set of credentials to rotate, another backup and restore procedure that someone has to test rather than assume, another failure mode in your incident taxonomy, another SDK to keep current, another vendor in your security review, another line in your data processing register, and another system whose upgrade path has to be scheduled around your release calendar. None of these are hard. All of them are recurring, and they are recurring against the scarcest resource in most engineering organisations: senior attention.

Then there is the part that actually causes outages, which is consistency. When embeddings live in one system and the rows they describe live in another, every write becomes a distributed transaction that you have almost certainly not implemented as one. A document is deleted from Postgres and its vectors linger. A tenant is offboarded and their embeddings survive in an index nobody audits. A re-embedding job half-completes and your retrieval quietly starts mixing two generations of model output. These are not exotic edge cases, they are the standard failure catalogue of dual-write architectures, and the standard fix is a reconciliation job that becomes load-bearing infrastructure nobody owns.

Keeping embeddings in the same database as the rows they belong to collapses that entire category. The delete is a foreign key cascade. The tenant filter is the same row-level security policy protecting the rest of the data. The join between a similarity result and the account, permission and status columns that decide whether the user may see it is a join, executed by a planner, inside one transaction, rather than an application-layer fetch-then-filter loop that is slower, more code, and wrong in ways that only show up in an audit.

This is one of the most common findings when our teams at Stepto pick up an AI system built by someone else: the retrieval architecture is not slow, it is over-decomposed. A dedicated team that has operated the system for a year rather than delivered it and moved on tends to reach a different conclusion about how many moving parts are worth keeping, because they are the ones who get paged when the reconciliation job silently stops.

Why Are the Platform Vendors Buying Postgres Companies?

If you want to know where infrastructure is heading, watch what the platform companies buy with real money rather than what they say at conferences. In 2025 and into 2026 the two most consequential data-layer acquisitions both pointed the same way, and neither of them was a vector specialist.

Databricks acquired Neon, the serverless Postgres company, in a deal reported at around $1 billion. The detail from that deal that should interest engineering leaders more than the price is the usage pattern Neon disclosed: roughly 80% of databases on the platform were being created by AI agents rather than by humans. Agents provisioning their own scratch databases at machine speed is a workload shape, and the shape it favours is a familiar engine with a cheap, instant, forkable instance, not a specialist store with a bespoke API.

Snowflake answered with its acquisition of Crunchy Data for around $250 million, launching an enterprise-grade Postgres inside its own cloud. Two platforms with opposing philosophies about analytics reached the same conclusion about the transactional layer that feeds AI applications, and both concluded it should be Postgres.

The developer numbers say the same thing from the other end. PostgreSQL has been the most-used database in the Stack Overflow Developer Survey for several years running, and it is still pulling away. An analysis of the 2025 survey data puts it at 55.6% of developers, up from 48.7% in 2024, roughly a 15 percentage point gap over second-place MySQL. When you choose Postgres for vector search you are choosing the engine your team already knows how to tune, back up, monitor and hire for. That is not a technical argument, it is a staffing one, and staffing is where most retrieval projects actually fail.

Is Retrieval Quality Even a Database Property?

Here is the uncomfortable part for everyone who spent a quarter evaluating vector engines: the engine is rarely what determines whether your retrieval is any good. Approximate nearest neighbour search is a well-understood problem with a small number of good algorithms, and every serious implementation has converged on similar ones. What varies enormously between two RAG systems is everything wrapped around the index.

The published evidence on this is consistent. A 2026 arXiv benchmark of retrieval strategies over text-and-table documents, From BM25 to Corrective RAG, found a two-stage pipeline of hybrid retrieval followed by neural reranking reaching Recall@5 of 0.816, against 0.695 for hybrid fusion alone, 0.644 for BM25 on its own, and 0.587 for dense vector retrieval. Read that last pair again: plain lexical BM25 beat dense embedding search on most metrics in that evaluation. The pipeline stage you did not build costs you more recall than the engine you agonised over.

Chunking is the same story one level down. If your splitter cuts a table away from its header or a clause away from the definition it depends on, no embedding model, index or reranker recovers the meaning that was destroyed before anything was stored. The dull work of getting document segmentation right for your specific corpus outperforms almost every glamorous change you can make elsewhere in the stack.

And underneath both sits evaluation. A team that cannot measure recall and answer quality on a labelled set drawn from its own documents is not making engineering decisions, it is making aesthetic ones. Once that harness exists, the vector database question usually answers itself in an afternoon: you run your corpus and your queries through both options and read the numbers. Teams without a harness argue about benchmarks published by vendors on datasets that look nothing like theirs.

What Changes When Agents, Not Chatbots, Do the Retrieving?

The architecture argument has also moved because the workload has. A 2023 RAG system answered one question with one retrieval pass. A 2026 agent runs a loop: it plans, calls tools, reads results, revises, and may touch retrieval a dozen times inside a single task, with each call needing different data of a different shape.

That shift is why context architecture has started displacing plain RAG as the way teams describe this problem. The reported buying behaviour tracks it: retrieval optimisation spending rose from 19% to 28.9% of AI infrastructure investment across Q1 2026, overtaking evaluation spending for the first time, and stated intent to adopt hybrid retrieval roughly tripled from 10.3% to 33.3% between January and March.

What an agent actually needs is not one similarity search. It needs a structured profile of the user it is acting for, the current state of the task, a set of semantic facts it can search over, an episodic history of what it already tried, and often a graph of how entities relate so it can answer a multi-hop question without twelve round trips. Those have genuinely different access patterns, and pretending they are all vector similarity is how teams end up embedding their database schema and being disappointed.

Notice what that does to the original question. If the retrieval layer for an agent is a composition of structured lookups, lexical search, similarity search and relationship traversal, then the engine that can do most of those in one place with one transaction and one permission model gets more valuable, not less. A single Postgres instance holding rows, JSON documents, full-text indexes and embeddings answers a surprising share of an agent's questions without a network hop, and a specialist vector store answers exactly one of them.

When Is a Dedicated Vector Database Still the Right Call?

There are workloads where the specialist is correct and choosing Postgres out of consolidation zeal would be an act of self-harm. The honest test is whether you can name the specific constraint that forces the move, in a sentence, with a number in it.

Scale is the clearest one. Somewhere north of a hundred million vectors, and certainly in the billions, the engineering that distributed vector databases have done on sharding, replication, quantisation and memory layout stops being a marginal advantage and becomes the reason the system works at all. The 2026 comparisons of pricing and scale limits across the major systems are worth reading precisely at that tier, because that is where the architectural differences show up in the invoice.

Tail latency is the second. If your product's contract with users is a p99 in the low tens of milliseconds under sustained concurrency, the benchmark numbers above are an argument for the specialist, and no amount of tuning changes the shape of that curve. The third is workload isolation: heavy, spiky embedding search sharing an instance with your transactional workload is a noisy-neighbour problem, and the answer may be a separate engine, though it may equally be a read replica.

The fourth reason is organisational and the most underrated. A team with no Postgres operations capability, no experience of vacuum behaviour, index bloat, connection pooling or the memory implications of a large HNSW build, will get a better outcome from a managed serverless vector service than from a self-hosted database they are not equipped to run. Consolidation only pays if someone can actually operate the thing you consolidated into. That capability question is one of the more common reasons clients bring in a dedicated nearshore team rather than another set of hands: the constraint is rarely the schema, it is having engineers who have run Postgres under load before and can say which of these four reasons applies to you.

What Does the Right to Erasure Do to a Vector Index?

For European teams there is a dimension of this decision that the performance blog posts skip entirely, and it is the one most likely to become somebody's problem in an audit.

Start with what an embedding is. The convenient assumption is that a vector is a lossy, one-way projection and therefore something like anonymised data. The research says otherwise. Inversion attacks reconstruct source text from embeddings with uncomfortable fidelity, with work in this line reporting reconstruction of up to 92% of a 32-token input from T5-based embeddings. If the source text contained personal data, the vector is personal data, and the entire GDPR apparatus applies to your index: lawful basis, retention, residency, subject access, erasure.

Erasure is where it gets architecturally awkward. A 2026 paper on soft-deleted embeddings in HNSW indexes shows that vectors marked as deleted commonly remain reconstructible from the graph structure, because approximate-nearest-neighbour indexes are built to make deletion cheap by making it lazy. Filtering a record out of query results is not erasure under Article 17, which requires deletion to be verifiable and irreversible. Most teams have never asked their vector store how it implements delete, and the answer frequently involves a tombstone and a compaction that runs when it feels like it.

Then there is jurisdiction, which is a separate question from geography and is repeatedly conflated with it. Pinecone's Frankfurt region, announced in May 2026, alongside its Irish and Netherlands regions, puts the bytes in Europe. It does not change the corporate domicile of the provider, and for organisations whose sovereignty requirements are drafted around control rather than location, that distinction is the whole point. It is why bring-your-own-cloud deployments exist, and why EU-domiciled engines are on more shortlists than they were two years ago.

Set against that, embeddings sitting in a Postgres instance you run inside your own EU infrastructure inherit the data protection posture you already documented, already tested and already had audited. That is not a small convenience. It is one fewer processor in the register, one fewer transfer mechanism to justify, and one system where a deletion request executes as a transaction rather than a support ticket.

How Should a Team Actually Run This Decision?

The decision is small enough to make in a week, and the reason it drags on for a quarter is almost always that nobody has built the evaluation harness that would end the argument.

So build that first. Take a few hundred real queries against your real corpus with human-labelled relevant documents, and measure recall, precision and end-to-end answer quality. Without it, every subsequent step is opinion. With it, you can run both candidate stacks on identical inputs, and you will also finally know whether your retrieval problem is the engine at all, which, as the reranking numbers above suggest, it usually is not.

Then write down the constraint that would force a specialist, before you look at any vendor material. Vector count in eighteen months. Required p99 under expected concurrency. Filtering pattern and tenancy model. Ingestion and re-embedding cadence. Deletion and residency obligations. If none of those constraints is violated by pgvector on the database you already run, the default is the database you already run, and the burden of proof sits with the second system.

If you are already running the split architecture, do not migrate on principle. Migrate when the reconciliation job, the drift, the duplicate permission logic or the deletion story has cost you a real incident, and then treat it as the schema and backfill exercise it is, with a shadow-read period where both stores answer and you diff the results before anything is switched off.

This is the kind of work a dedicated team is well suited to and a rotating project team is not, because the payoff is measured over quarters. Stepto builds long-running teams of senior engineers in Serbia who stay with a product rather than a project, which means the people who choose the retrieval architecture are the people who operate it a year later and who will be paged when the nightly sync stops. Working from Central European hours, inside the EU regulatory perimeter, also means the GDPR and residency questions above are shared constraints rather than clauses translated across a jurisdictional gap. If your AI feature is stalled, the bottleneck is more often an over-decomposed data layer and a missing evaluation harness than a model choice, and both are fixable with senior engineering rather than a bigger vendor.