· Updated October 25, 2026 · 10 min read

Is your data layer ready for agents? The case for Lakebase

#agents #databases #lakebase #postgres #production

Part 3 of 3 · Agents and the data layer

Agents add a newer job for databases: keeping what they remember, and giving them a safe place to work. What that asks of the data layer, and where Lakebase fits.

A navy ledger kept inside a dashed boundary with a check mark, beside loose and crumpled paper copies outside it
On this page

Two booking agents both see one room left at the hotel for next month’s sales kickoff in Chicago. Both book it. Two colleagues now share a room neither of them agreed to.

That’s the problem this series has been building towards. The company is sending two hundred people to the kickoff, with an agent booking each trip. Every booking goes straight into one shared system, and that’s where a mistake costs something. Meanwhile, coding agents keep changing the travel tool itself, and each change should be tested on a copy of the data before it ships.

The first two parts set the bar for that data layer:

  • Part 1: the approval and the ticket are records. They have to survive a crash. Before retrying an unfinished booking, the agent still checks with the airline.
  • Part 2: coding agents need a scratch copy of the database to test software changes on (part 2 calls it the practice kitchen), and the record has to stay right when many booking agents write at once.

In What is an enterprise agent?, every step goes propose, check, approve, act, verify. The model only proposes. Everything after that has to be enforced by the system, and a relational database is one of the oldest, most proven parts of it. Its transactions make related writes succeed or fail together. An airline charge or an email sits outside the database, so those still need retry handling and a check on how they turned out. And no database can promise the agent chose well. That part is still on us.

So the question for any data layer is how much of that it gives you, and how much you have to build.

Where Lakebase fits

Lakebase is Databricks’ managed Postgres. It has been generally available on AWS since January 2026. Databricks agreed to acquire Neon, the serverless Postgres company, in May 2025, and Lakebase Postgres is also offered on Neon.com. I’ll keep the product detail light and follow the trip. The links go to Databricks’ own docs.

The practice kitchen

Copies that don’t really copy. When a coding agent adds roommate preferences to the travel tool, it needs a copy of the database to test the change on, never the live bookings. A Lakebase branch looks like a full copy of your database, but it points at the original data and stores only what the agent changes. So it appears instantly, whether the database is small or huge. Each branch keeps its own permissions, so a change on one doesn’t leak into another.

Letting idle compute sleep. A test branch sits idle most of the time: the coding agent runs its tests, then moves on. Idle compute can go to sleep and wake on the next query. Databricks says waking takes “a few hundred milliseconds”; that’s its own number, not an independent benchmark. Sleep isn’t available when a compute’s maximum size is above 32 compute units, or with high availability. A branch set to expire is billed for storage only on what changed, plus compute while it runs. A permanent branch is billed for its full size.

None of this is new as an idea. Part 2 showed compute and storage were separated long before agents. What matters for agents is that branching, sleeping and restore are on by default for new Lakebase databases.

The record

Agent memory has a home. Databricks documents Lakebase as the place to keep agent memory: where a conversation got to, and what the agent carries into the next one. Part 1’s split still applies. Some of that is scratch, and some is record. It works with LangGraph and the OpenAI Agents SDK. A Model Serving integration, in Public Preview, can resume or fork a conversation from a saved checkpoint. That tells part 1’s crashed agent where it got to. It doesn’t stop it booking twice. Checking with the airline is still the application’s job.

The familiar rules still apply. This is the plain heart of my case. Lakebase is Postgres. So part 2’s rules, one-step check-and-change for the last room and request numbers for retries, use ordinary transactions, conditional updates and unique operation IDs. These are established Postgres techniques. The application still has to wire them into the agent’s workflow.

Rewinding without losing your colleague’s booking. Point-in-time restore doesn’t overwrite your live database. It creates a new branch showing the data as it was at the moment you pick. It can go back as far as your retained history: seven days by default, up to 30. For part 2’s bad profile change, you restore 9:59 into a separate branch. Your application then copies back the old profile, with a conditional update that only applies if nobody has changed it since. Otherwise it stops for review. The 10:05 booking stays.

Finding the right memory

Keeping the record safe is half the job. The agent also has to find the right detail for its next step. It might search by meaning (“the colleague who won’t take a red-eye”) or by exact words (a booking reference). Lakebase does both inside the same Postgres. Once text is turned into numbers that capture its meaning, called embeddings, its pgvector extension finds records with similar meaning, and Lakebase Search combines meaning and exact-word search in a single query.

The travel policy and the employee directory probably live in the lakehouse already. Synced tables copy tables from the lakehouse into Lakebase and keep them up to date. In continuous mode, Databricks describes the delay as seconds. Databricks recommends treating these copies as read-only, so give agents read access only.

The paper trail

Finding data raises a question of authority: which records may this agent read? If you register a Lakebase database in Unity Catalog, you get a read-only catalog. Queries through that catalog, from Databricks serverless compute, get the same permissions, lineage and audit logs as the rest of your data. Agents that connect straight to Postgres use Postgres permissions instead. So decide which door your agents come through.

Change Data Feed, in Public Preview, copies inserts, updates and deletes from the schemas you choose into the lakehouse. It records what changed and in which transaction. It doesn’t record who asked, or why. Your application has to write that down.

What it leaves to you

Authority scoped to a single task, a cap on total spend, and a full record of who asked for what are still yours to build.

How others approach it

Lakebase isn’t the only answer, and the industry hasn’t settled on one design:

  • Snowflake Postgres became generally available in February 2026 in selected AWS and Azure regions. Each instance runs “on a dedicated virtual machine managed by Snowflake” (release note).
  • Supabase announced in October 2026 that it is acquiring Turso, whose design can give each agent its own small SQLite-based database on demand. Supabase says “Postgres is what you want as your application scales.”
  • Aurora has separated compute and storage since at least 2016, as AWS described then. Aurora Serverless v2 can pause automatically when idle.

Same pressure, different architectures. My case for Lakebase is narrower than “it’s the only way.” One Lakebase project can hold the agents’ practice branches and the databases for memory and business data, next to the lakehouse. For teams already on Databricks, keeping those pieces together is the practical appeal. One caution for the kickoff: 200 agents don’t mean 200 branches running at once. The default limit is 20 concurrently active computes per project, not counting the default branch. I’d share compute where it makes sense, and plan for that before the kickoff.

What’s still open

Prompt injection. Branches and permissions limit what a fooled agent can touch. They don’t stop it being fooled. Supabase has warned that read-only access through its MCP integration, which lets an agent query the database, still doesn’t stop prompt injection from leaking data. That holds for any database, Lakebase included.

The view across all agents. When agents create many short-lived databases, someone needs to see across them. Change Data Feed into the lakehouse is one route, but it’s in Public Preview, and it’s still a copy to manage.

Evidence. The adoption figures in part 2 are self-reported. And the customer stories Databricks cited at GA, such as easyJet and Hafnia, are application builds, not agent memory. Agent memory on Lakebase is documented and supported. Databricks now describes Zillow using Lakebase as the agent memory layer for its AI Mode, for conversation history and context. That’s a vendor-published customer story, not an independent test of recovery or retries.

Open questions

  • How do you prove, after the fact, that an agent stayed inside the authority it was given?
  • When the workspace expires, what exactly should be promoted into the record, and who decides?

So here’s the bar I’d hold any agent-ready data platform to, Lakebase included:

If an agent got your data wrong, could you see what it did and undo it without losing anyone else’s work? And could you stop it happening again without a person checking every change?

Lakebase gives you strong pieces for that: durable checkpoints, branches that don’t really copy, restore beside the live data, and Unity Catalog governance for registered reads. The application still has to do its part. Stable operation IDs, conditional updates, and side effects that are safe to retry.

If you’re putting agents in front of real data, I’d like to hear where your data layer held up and where it didn’t.

Sources

Sources checked on 2026-10-25. Dates are publication or last-updated dates where shown.

Disclosure: I work at Databricks. This post makes the case for Lakebase, so every Lakebase claim links to Databricks' own docs, dated in the sources below. Figures from any vendor, including Databricks, are labelled self-reported.

continue reading

What is an enterprise agent?

An enterprise agent isn't simply a model with tools. It's a system that pursues delegated goals, takes consequential actions, works within defined authority and keeps a clear line of accountability.

Building the AI-ready data platform

Capable agents can still fail on stale or ambiguous data. What an AI-ready analytical platform needs, and why I favour a lakehouse foundation.

Data is the bottleneck in the agentic era

Agents need dependable data, and they create records of their own. Why I think data delivery becomes the constraint once the model can do the job.