The Database Got a New User: Record Stores and Context Layers for Agents

In one line: the database’s main user stopped being a person, so it grew a second leg — one that holds state and provisions on demand, one that supplies context and compiles it ahead of the query. What really changed is the definition of retrieval: from a recall algorithm to an orchestration frame plus a compiled supply.

1. The problem, as a scene#

Start with a minor change that is not minor. Supabase rewrote every error message it emits. No more 500 Internal Server Error returned bare. The text now explains why the error fired, which command fixes it, and which URL holds the document that explains it.

The motive is retention. A human programmer meets an opaque error and opens a search tab. An agent meets the same error, gives up, and switches to a competitor. What the two vendors are competing over is whether the caller tries once more after it gets stuck.

Underneath sits a larger fact: every design assumption in a database was built on “the user is a person.” Dashboards are clicked by people. APIs are called by people. Errors are read by people. Instances are sized by people. Take those assumptions away one at a time and what remains is what an agent needs.

Three breakages with numbers behind them:

The third is the hard one. The first two are engineering. If every question starts its exploration from zero, then every order of magnitude of data adds an order of magnitude of cost and latency.

2. Where the research stands#

Eighteen months of work compresses into five checkable claims, each with a consequence.

Read together, they describe one thing: the leverage in this round is who delivers context to the model at the lowest cost. Storage is commoditised; context is not.

3. The design#

Lay the vendor approaches side by side and four requirements fall out. Miss one and a specific scenario breaks.

1. Provisioning must collapse toward zero. An agent will create a database for one task and discard it. The price has to follow — SQLite runs millions of databases on one server; a Postgres instance does not.
2. The interface is code and protocol. Agents do not open dashboards. They read CLIs, source files, and tool descriptions over MCP. Anything the dashboard can do, the code path must do too.
3. Failure must self-heal. The error message is the new documentation, and the new UI.
4. Context must be compiled and traceable. An answer has to point back to the exact span of source text, not a cosine-similarity guess.

On top of that sit two principles that decide the shape of the architecture.

Principle one: the record store and the context layer are separate. The raw-text channel and the derived-content channel stay isolated — retrieval over source text never returns compiled artifacts, and compiled structure only enters context through compilation tools. Derived knowledge does not impersonate source, and source is not buried under structure.

Principle two: decisions are layered by kind. The harness owns what cannot be delegated (is the evidence sufficient, should it be sent, what citation number it gets). The model owns what it is genuinely good at (which words to search, which document to open, whether a passage is relevant). The engine owns mechanical execution (match, rank, filter). Systems that blur the three degrade into the same loop: rewriting one keyword set until the budget runs out.

4. The implementation#

4.1 Supply layer: the database as a disposable file#

The most radical branch treats the database not as durable infrastructure but as a lightweight, discardable artifact: creating one should be as simple as minting a unique ID, with an embedded engine (SQLite, DuckDB) doing the storage.

The evolutionary branch answers from the other end. Tiger Data added a storage layer to Postgres that supports zero-copy forking, so an agent can test a schema change or a migration on an instantaneous branch of production. Neon’s copy-on-write branching became the substrate of Databricks Lakebase after the acquisition. OceanBase’s seekdb puts FORK/MERGE sandboxes directly in the pitch.

Supabase’s choice is the most legible: keep Postgres and push it up to petabyte scale (Multigres for connection pooling and multi-node failover, OrioleDB for storage), buy Turso to push the floor down (SQLite lineage, Rust rewrite, millions of databases per server), and slot a lighter Spark in between (Rust, a SQLite engine behind a Postgres-compatible SQL layer, PostgREST- and Auth-compatible APIs). Their own phrase for it is “from prototype to petabytes.”

Worth recording is the commercial logic. Roughly 40% of AWS revenue comes from customers who started there on day one and grew. Convincing anyone to migrate a database is close to impossible, so the only viable strategy is to be present at day one.

4.2 Interface layer: MCP and code-first#

The agent’s interaction modality has converged: CLI, code, MCP. By 2026 most major database platforms ship an official MCP server, and a dozen third-party ones exist (Google MCP Toolbox, DBHub, Postgres MCP Pro).

The shape of Google’s MCP Toolbox is the interesting part. It is a control plane: operations are pre-declared and parameterised in tools.yaml, and the agent calls them by name instead of composing statements. That is good news for enterprise compliance: “agent talks to the database” will be replaced by “agent talks to the database through a governance layer.”

Supabase’s own three-stage self-description is worth copying as a coordinate: a dashboard company, then an API company, now a code-first company. Each turn was forced by the previous stage’s users walking away.

4.3 Compilation layer: move the understanding upstream#

The fatal property of naive RAG is not that it searches badly. It is that every query is a cold start: the system does not remember what it understood last time, how the documents relate, or which sources are authoritative. Karpathy’s LLM Wiki names the pain precisely — knowledge is compiled once and kept current, instead of being re-derived on every query.

Pinecone Nexus productises it: a Context Compiler turns raw data into persistent knowledge artifacts, served by a retriever with field-level citations and deterministic conflict resolution, queried through a declarative language called KnowQL. Its own positioning is blunt — a knowledge engine, not a retrieval system.

RAGFlow’s version is more engineered: six artifact shapes sharing one lineage model.

One counter-intuitive engineering finding deserves its own paragraph: organising documents into a tree does not, by itself, help agentic search. Inside a well-built harness, a conventional chapter tree can even be a liability — the agent still leans on search and grep. What produces the gain is the evidence chain hanging off the leaves: navigating to a leaf returns a claim plus verbatim evidence, not the whole passage.

4.4 Orchestration layer: the harness is the engine, compilation is the supply#

Line the two halves up and the division is clean: the search harness finds it, knowledge compilation makes it cheap to use.

RAGFlow 1.0’s harness did a subtraction. It removed the routers that split traffic by latency, freshness and query type, leaving a single loop — but re-drew who decides what. The loop carries a few disciplines, each answering a specific failure mode:

• Evidence first. Before the model thinks about how to search, the framework runs one cross-corpus recall and pulls back compiled atomic claims.
• Two-way fork. If the evidence is sufficient (enough claims, enough distinct sources), one model call writes the answer and no source text is read at all. If it is insufficient, the whole block is discarded — not written into the system prompt (the loop would bill it on every call), and not given citation numbers (the model never saw it). The default elsewhere is to stuff whatever was retrieved into context; this does the opposite.
• Citations are mechanical. Evidence is numbered the moment it is delivered, and a passage keeps the same number for the whole session. The model cannot cite something it never read, because numbering is assigned at serve time rather than reconstructed afterwards by similarity.
• The evidence gate. It does not rerank. It answers a question one step earlier: does this batch of evidence need to go to the model at all? Its value is in deciding not to send.

What holds this together is three things: decisions layered by kind, a minimal sufficient evidence set, and mechanical citation and cost accounting.

4.5 The other leg: keep the state yourself#

The four layers above answer “where does knowledge come from.” The Personal Database branch answers “where does state live.”

Its argument is about sovereignty. If your working habits, your daily process and your CRM all live inside one agent, you cannot switch when a better one appears. Pull the data into an independent personal database and the agents and models above it become interchangeable.

The workload decides the architecture: enormous in count, tiny in size, and bimodal in lifetime — either minutes (a prototype) or decades (a lifetime). Neither extreme suits “one virtual machine per Postgres.”

5. Trade-offs, with their costs#

One controlled experiment has to be set down here because it discounts the compile camp’s story: the preregistered comparison in arXiv:2605.18490 found that an agentic RAG using only string matching already comes close to an LLM-compiled wiki. Compilation’s gain is cost and traceability.

The critique of compilation also holds. Every editorial decision an LLM makes while writing a wiki is a doorway for hallucination, and once it enters the record it is no longer labelled a hallucination — it is labelled a line of notes. RAGFlow counteracts this by requiring every claim to be bound to a contiguous verbatim substring as evidence. That is an engineering answer, not a theoretical one.

6. Where it stands#

An honest reading: both legs are early, and both rest on vendor-published numbers.

Most of Supabase’s ~50 million databases are free prototypes. “70% of new activity comes from agents” measures activity, not revenue. The AWS day-one rule only holds if some of those databases grow up, and the conversion rate is not public.

The compilation ledger needs the same discount. Pinecone’s internal benchmark reports a 2.8M-token financial analysis task dropping to 4,000 tokens, a 98% cut. RAGFlow reports >90% savings per question when the evidence chain hits, ~2% loss when it misses, and 30–40% average savings on the FRAMES multi-hop benchmark. None of it has been independently reproduced, though the direction agrees with the PwC experiment.

Only three things have genuinely landed and can be treated as settled: MCP became the de facto standard, branching and sandboxing became the default posture for agent workloads, and error messages started being rewritten as product surfaces.

7. Numbers, with sources#

8. What this buys you#

No database migration required. One afternoon:

1. Take 20 real questions from your RAG pipeline and build a baseline harness with grep/BM25 and a plain loop. Run it head to head against the vector pipeline. If PwC’s result does not hold on your corpus, your data distribution is the exception — write down why.
2. Measure three numbers: mean iterations per question, tokens entering context per iteration, and whether the final citations resolve back to exact source spans. The second decides cost; the third decides whether you pass an audit.
3. If your corpus is long documents or a policy set, try evidence chains as a pre-chunk filter: answer from the evidence and never read the source. Divide the tokens saved by the indexing cost to see the payback period.

After those three steps you will know whether you need an “agent database” or just a better harness.

9. Roadmap and open questions#

Two questions I cannot answer, left here on purpose.

First, does the payment structure hold? Provisioning millions of small databases can be pushed close to free, but where does revenue come from — the few long-tail databases that grow up and start paying, or metered agent usage? The first bets on conversion, the second on volume, and the unit economics are entirely different.

Second, can compiled artifacts be moved? Evidence chains, ontologies, navigation trees and memory templates are mutually incompatible across vendors. A personal database frees you from lock-in to an agent vendor, but may lock you to a database vendor instead. That is the largest unsolved problem in this category, and the only thing worth writing into a procurement contract today.

References#

• Supabase, Supabase is acquiring Turso — https://supabase.com/blog/supabase-is-acquiring-turso
• Supabase, $150M in new funding and Turso acquisition (press release, 2026-10-02) — https://www.prnewswire.com/news-releases/supabase-announces-150m-in-new-funding-and-turso-acquisition-302896752.html
• Y Combinator, What happens when everyone can build software (Paul Copplestone)
• Gartner, AI Vendor Race: The Future of the Database Market Belongs to Agentic Unified Decision Engines (2026-03) — https://www.gartner.com/en/documents/7552005
• IDC, Operationalizing Agentic AI: Why the Data Layer Is the New Control Plane (FERS, 2026-02)
• PwC, Is Grep All You Need? How Agent Harnesses Reshape Agentic Search, arXiv:2605.15184 — https://arxiv.org/abs/2605.15184
• Vector RAG vs LLM-Compiled Wiki, arXiv:2605.18490
• Microsoft, AgenticRAG: Agentic Retrieval for Enterprise Knowledge Bases, arXiv:2605.05538
• Pinecone, Nexus: The Knowledge Engine for Agents (2026-05-04) — https://www.pinecone.io/blog/knowledge-infrastructure-for-agents/
• RAGFlow, What Is Agent Native Database? — https://ragflow.io/basics/what-is-agent-native-database
• Gradient Flow, Inside the race to build agent-native databases — https://gradientflow.com/inside-the-race-to-build-agent-native-databases/
• VentureBeat, The RAG era is ending for agentic AI — https://venturebeat.com/data/the-rag-era-is-ending-for-agentic-ai-a-new-compilation-stage-knowledge-layer-is-what-comes-next
• OceanBase, seekdb — https://github.com/oceanbase/seekdb/