How can Lakebase support Agent Bricks applications that need to read and write operational data?

Summary

• Lakebase is Databricks' fully managed serverless Postgres, and it gives an agent application a transactional database to read the context it acts on and write back what it does, using standard SQL with ACID guarantees.
• Because Lakebase speaks standard Postgres, an Agent Bricks application, or an agent built with Agent Framework, LangGraph, or the OpenAI Agents SDK, connects directly with ordinary drivers, with no custom data layer to build.
• Serverless compute autoscales to match bursty agent traffic and scales to zero when idle, so one request that fans out to many agents doesn't need pre-provisioned capacity.
• Synced tables bring governed lakehouse data into Lakebase for low-latency reads, so agents work on fresh operational and analytical context in one place.
• Lakebase is governed by Unity Catalog, and its Change Data Feed lands every row-level change as Delta history, so an agent's reads, writes, and state stay auditable end to end.

How can Lakebase support Agent Bricks applications that need to read and write operational data?

Agents need two things from their data: context to act on, and a place to record what they do. Lakebase, Databricks' fully managed serverless Postgres, gives an agent application both. It runs standard Postgres right next to the lakehouse, so an agent reads the records it needs and writes back its decisions and results as ordinary transactional rows, with the ACID guarantees operational work depends on. For an application built with Agent Bricks, that read and write path is a governed database, not a bolt-on cache.

What is Lakebase?

Lakebase is an operational Postgres database built into Databricks, powered by Neon, the serverless Postgres engine Databricks acquired in 2025. It separates compute from storage and keeps operational data in open format on the lakehouse, so the same records serve low-latency application reads and writes and, once registered in Unity Catalog, analytical queries. Lakebase is generally available. Because it is standard Postgres, existing drivers, ORMs, and application components connect to it directly.

What an agent application needs from its operational database

An agent that reads and writes live data has requirements a plain analytics store doesn't meet:

Capability	Why it matters for agents
Transactional reads and writes	Agents record actions, decisions, and outcomes as they run, so those writes need ACID guarantees and are never half-written or lost.
Low-latency serving	An agent in a loop reads context on every step, so read latency shapes how responsive the whole application feels.
Elastic, bursty scaling	Agent traffic is spiky, and one request can fan out to many agents at once, so the database has to absorb bursts without pre-provisioning.
Fresh operational and analytical context	Agents act better when live app data sits next to governed features and history, with no separate pipeline to join them.
Unified governance and audit	Every read and write an agent makes should inherit the same permissions, lineage, and audit as the rest of the platform.

How Databricks approaches this

Point the agent application at Lakebase for its operational state. Briefs, tool results, user preferences, and the actions the agent takes become ordinary Postgres rows the application reads and writes with transactional guarantees. Because Lakebase is standard Postgres, application components drop straight onto it with no bespoke data layer, and it autoscales in milliseconds to meet bursty demand, then scales to zero when traffic stops.
To give agents analytical context, synced tables bring Unity Catalog data into Lakebase for low-latency reads. You pick a source table and a sync mode, and the pipeline is fully managed: continuous mode keeps the copy within seconds of the source, and triggered mode updates on a schedule. Agent memory has a first-class path too. Agents built with LangGraph or the OpenAI Agents SDK store conversation state and long-term memory directly in Postgres, and models served through Model Serving read features from Online Feature Stores powered by Lakebase.
Governance and analytics come from the lakehouse side. Registering the Lakebase database in Unity Catalog applies one set of permissions, lineage, and audit across the agent's operational and analytical access, and lets a single query join the agent's live rows with historical tables. The Lakebase Change Data Feed captures every row-level change from Postgres as Delta history, so downstream pipelines, dashboards, and audits can track what the agent did without touching the operational database. Background is in the Databricks blog on serverless databases for AI.

Use cases

Operational agent applications. An agent reads live inventory, pricing rules, or account records, takes an action, and writes the result back as a booked transaction, all in one Postgres database.
Stateful, resumable agents. Conversation checkpoints and long-term memory persist in Lakebase, so an agent picks up where it left off and its history stays durable and queryable.
Serving models and features. Agents and models read fresh features from Online Feature Stores powered by Lakebase, keeping feature reads low-latency with no separate serving system.

FAQs

Does an Agent Bricks application need a custom data layer to use Lakebase?

No. Lakebase is standard Postgres, so agent applications and their components connect with ordinary Postgres drivers and SQL. There is no bespoke serving layer to build.

How does Lakebase handle unpredictable agent traffic?

It is serverless. Compute autoscales in milliseconds to absorb bursts and scales to zero when idle, so a request that fans out to many agents doesn't require pre-provisioned capacity.

Are an agent's reads and writes governed?

Yes. When the Lakebase database is registered in Unity Catalog, operational and analytical access share the same permissions, lineage, and audit, so every read and write is governed.

Can I analyze what an agent wrote without slowing it down?

Yes. The Change Data Feed lands row-level changes as Delta history on the lakehouse, and analytical queries run on lakehouse compute isolated from the database, so reporting never competes with the agent's transactions.