Lakebase Changes the Lakehouse Architecture Conversation

Shannon Lowder

20 Jun 2025 — 1 min read

Databricks announced Lakebase at DAIS — a fully managed, Postgres-compatible operational database built on their acquisition of Neon. The announcement landed harder than I expected, because it isn't just a new product. It's a structural argument that the lakehouse can absorb the OLTP workload that's always been its obvious gap.

The pitch: one platform for transactional and analytical workloads, with shared governance, shared catalog, shared access control. No ETL hop from your operational database into your warehouse. The data is just in the same place.

What Neon Brings

Neon is a serverless Postgres with instant branching and compute-storage separation. Branching means you can spin up a copy of your production database for testing, a feature branch for a new schema, or an ephemeral dev environment in seconds without duplicating storage. The Databricks integration means that Lakebase tables appear in Unity Catalog alongside your Delta tables — same permissions model, same lineage tracking, same access control.

That last part is significant. Managing two permission systems — one for your operational database, one for your warehouse — is one of the most consistent sources of governance drift I see in client environments. A shared catalog eliminates it.

The Architecture Question It Raises

If your operational database lives in Lakebase and your analytical tables live in Delta Lake, the traditional ETL pipeline between them collapses into a materialization step — or disappears entirely if your analytical queries can run against Lakebase directly. That changes the role of pipelines like Lakeflow and DLT: they're no longer moving data from operational to analytical storage; they're transforming data within a unified platform.

This is early. Lakebase is new, Postgres-compatible means "mostly Postgres," and serverless transactional databases have their own cost curves. But the direction is right. I'm here to help think through what it means for your architecture.

The Context Problem Neither Agent Mesh Nor OpenSharing Solves

I wrote recently about Azure Agent Mesh and OpenSharing — two infrastructure layers that between them cover how enterprises register, discover, share, and execute agents. Between them, they address a lot of the plumbing that has been missing from the enterprise agent stack. But there's a gap neither of

Unity AI Gateway and What a Governed Model Access Layer Actually Buys You

Unity AI Gateway, announced at DAIS this week, is the feature I've been waiting for since Agent Bricks shipped last year. It's a centralized governance layer for model access in Databricks — you configure which models are approved for use in your environment, who can call them,

You Don't Need Fable. You Need a Router.

The performance gap between open-weight models and closed frontier models has spent the last year collapsing faster than anyone predicted. Epoch AI's tracking puts open weights at roughly a three-to-four-month lag behind state-of-the-art closed models on average. For coding tasks, the gap has effectively closed — DeepSeek V3.2

DAIS 2026: Genie One and the Context Problem Databricks Is Solving

The central message from DAIS this week, delivered by Ali Ghodsi in the opening keynote, was direct: AI doesn't have an intelligence problem, it has a context problem. If your CFO can't get an AI system to explain why margins changed, that's not a