The database was the last thing we optimized for agents. It should have been the first.

For most of the last two years, the interesting part of building an AI product happened above the database. Prompts, then context, then orchestration graphs. The database sat underneath as a solved problem: a Postgres instance somebody provisioned once, plus a vector store bolted on the side because Postgres "could not really do search."

That last sentence stopped being true, and it changes the shape of the stack more than any framework release this year.

This is the reasoning behind a decision we made across our product portfolio at Rather Labs: Neon is our default Postgres for anything with an agent in it. Here is the argument, including the parts where the competition is still the better answer.

Agents broke two assumptions at once

The first assumption: databases are provisioned by humans.

In a classic SaaS backend you create one database per environment. Three, maybe five, over the life of a product. In an agent product you create one per tenant, per sandbox, per pull request, per agent run. Replit runs over 300,000 Postgres instances on Neon with a single infrastructure engineer. Specific.dev provisions thousands of databases a month, each in about a second. Most of those databases are idle most of the time, and a meaningful share are abandoned entirely.

That is not a scaling problem, it is an economics problem. A pricing model with a per-instance floor makes a fleet of mostly-idle databases structurally unaffordable, no matter how good the engine is.

The second assumption: retrieval is a one-shot step.

Classic RAG is embed, search once, stuff the context, answer. Agentic retrieval is a loop: search, read, decide the answer is incomplete, decompose, search again with a narrower query, sometimes six or eight times before responding. Every iteration in that loop pays the full cost of your retrieval architecture. If retrieval means a network hop to a separate vector service, plus a second hop to a keyword index, plus a join back into Postgres to filter by tenant and permissions, you pay that tax on every turn, and you pay it in latency the user feels.

We felt exactly this on an HPC project a while back. We built an external search layer with Pinecone because there was no other credible option. It worked. It also meant three systems, two of which had to be kept in sync with a job that could silently fall behind, and a retrieval path that could never do a transactional join against the operational rows.

The reason nobody did this in Postgres before

The standard answer was pgvector, and pgvector's HNSW index is genuinely good. It also lives in RAM.

That single fact is what made vector search and serverless Postgres mutually exclusive. Scale to zero, and the index cache evaporates. Come back, and you rebuild or rewarm before the first query returns, which turns a cold start into minutes. So you had two options: keep compute permanently warm and pay 24/7 for a database that serves traffic 4% of the time, or move vectors to an external service that stays warm on somebody else's bill. Almost everyone picked the second, and then inherited the sync problem.

At real scale the memory math gets worse fast. A 100 million vector HNSW index wants roughly 300GB of RAM. That is not a serverless workload, that is a dedicated machine with a monthly invoice attached.

What Lakebase Search actually changes

Neon shipped Lakebase Search as two Postgres extensions, and the design decision that matters is not the ranking algorithm. It is where the index lives.

lakebase_vector adds a lakebase_ann index type. It uses IVF partitioning with RaBitQ quantization, compressing vectors roughly 32x, which takes that 100M vector index from ~300GB as HNSW to under 10GB. Index builds run 50 to 100x faster than the HNSW equivalent, and a single index scales past a billion vectors. Critically, it keeps 100% compatibility with pgvector types and distance operators, so existing queries do not change.

lakebase_text adds lakebase_bm25: real BM25 ranking with top-K pushdown via Block-Max WAND, so the engine returns the K most relevant documents without scoring every match. Postgres' native GIN index cannot do that, which is the actual reason so many teams ended up running Elasticsearch next to their Postgres.

Both indexes sit on object storage, with a tiered cache underneath them: RAM, then local NVMe, then pageserver, then object storage. Three consequences follow, and they are the whole point:

1. Indexes survive scale to zero. There is nothing to rebuild, because nothing was in RAM to lose. Cold start goes back to being a compute problem, roughly a second, instead of an index problem measured in minutes.
2. Branches inherit indexes instantly. Branching is copy-on-write, and the index comes with it. You can fork production, test a different fusion strategy, and throw the branch away.
3. Hybrid search is one SQL query, in one transaction. Keyword and semantic, joined against your operational tables, filtered by tenant or permission or date, with no sync job in the picture.

The architecture collapses from this:

Postgres      (source of truth)
+ Pinecone    (vectors)
+ Elastic     (keyword)
+ sync jobs   (hope)

to this:

Neon Postgres (data + search + vectors)

For an agent loop specifically, the second diagram is not just simpler, it is more correct. The index cannot be stale relative to the row, because it is the same transaction. An agent that retrieves stale data does not fail loudly, it answers confidently and wrong, and that is the most expensive failure mode in the category.

The part that surprised us

Neon also published a result with Castform: a 4B parameter open-source model, RL post-trained specifically for agentic retrieval, matching a frontier model's search quality at roughly 1/100th the cost per request. Their reference point for the frontier baseline is a multi-turn search taking over 10 seconds and costing about $0.03 end to end.

Those are Neon's numbers on Neon's benchmark and we have not reproduced them, so treat the exact multiple with the skepticism it deserves. The direction is what matters. If retrieval quality can be trained into a small model that runs beside the corpus, then the expensive frontier model stops being the retrieval engine and goes back to being the reasoning engine. The loop moves into the database. Which means the database's ability to serve that loop cheaply, in one query, with the index always fresh, becomes the constraint on the whole system.

That is a very different thing to optimize for than "Postgres with vectors available."

Where the competition actually wins

We are not arguing Neon dominates on every axis. It does not.

Supabase is the better call when you want the whole backend in one box: auth, storage, realtime, edge functions, and row level security that is genuinely well designed. If your product is a conventional multi-tenant app with a chat feature attached, Supabase gets you further faster. The tradeoffs for our use case: vector search is pgvector, so the RAM problem above is still yours to solve, and preview branches are data-less by design. Data-less branching is a defensible security decision, but it is not the same primitive as forking production data and its indexes in seconds, and that primitive is exactly what makes agent sandboxes cheap.

Aurora Serverless v2 now scales to zero, and AWS has been shipping specifically for agentic bursts. If you already live inside AWS with the compliance and networking gravity that implies, it is a serious answer. What it does not give you is data branching, and provisioning a new cluster is still a minutes-scale operation, which rules out the database-per-agent-run pattern entirely.

PlanetScale remains excellent at high sustained QPS with strong schema change ergonomics. It is built for one large database that is always on, which is the opposite of a fleet of ten thousand mostly-idle ones.

Turso and the SQLite family are arguably the cleanest answer for embedded per-tenant databases at extreme cardinality. The cost is leaving the Postgres ecosystem: extensions, Prisma's maturity, and the analytical path out the back.

Pinecone, Qdrant, Weaviate still beat Postgres on pure vector features at the top end: exotic filtering, multi-vector, and specialized index types. If vector search is your product, use a purpose-built engine. If vector search is a feature of an application whose source of truth is relational rows, a second system is a liability you pay for daily.

And the honest limits on Neon itself: it is not where you run heavy analytics, sustained bulk write throughput is not its strongest axis, and Lakebase Search is new enough that you should benchmark it against your own corpus rather than trusting anybody's blog post, including this one.

The Databricks angle

Neon was acquired by Databricks, and Neon and Databricks Lakebase are now the same engine in two environments. Neon is the developer and agent-platform surface; Lakebase is the governed enterprise surface inside the lakehouse.

For our enterprise clients this de-risks the choice in a way that is easy to underrate. The operational database and the analytical platform stop being separate procurement decisions with a pipeline between them. You start on Neon because it is fast to build on, and the path to Unity Catalog governance exists without a migration. For a services company that has to defend architectural choices to a client's CTO three years out, "there is a credible enterprise path from here" is worth more than a benchmark.

How we actually use it

Across TranscribeGo, Clinsia and Radarial, the pattern is consistent:

• One branch per pull request, seeded from real production shape, torn down on merge. Preview environments stop being a build step and become a database operation.
• Agent memory in the same database as the operational rows. Conversation state, embeddings and the business records they refer to are one join away, filtered by tenant in the same query, inside the same transaction.
• Scale to zero on everything pre-revenue. Internal tools, client demos, abandoned experiments. They cost nothing while nobody is using them, and they answer in about a second when somebody does.
• No Pinecone. One less system, one less credential, one less sync job that can be silently wrong.

The stack fits without friction: Prisma, Next.js on Vercel, Neon underneath. That is not a small thing. Most of the cost of infrastructure decisions is not the infrastructure, it is the integration surface.

The criterion

We do not pick a database for what it costs at steady state. We pick it for what it costs to be wrong.

The agent workload we are designing for today will not be the one we are running in eighteen months. What we can predict is the direction: more databases, more ephemeral, more retrieval per request, less human in the provisioning loop. The choice that survives that is the one where creating a database is an API call, destroying it is free, forking it is instant, and search is a column type rather than a second system.

Today that is Neon. If it stops being Neon, the fact that it is still just Postgres is what makes that reversible.

---

Rather Labs builds AI and blockchain products for companies that need them in production, not in a demo. If you are designing agent infrastructure and want a second opinion on the data layer, get in touch.