Every Databricks conference has had a "look, we built a Databricks App!" demo. Twenty minutes, one screen, three buttons, cue polite applause. None of them tell you what happens when you have to handle concurrent users, real volumes of inserts and updates and the operational realities of an app people actually depend on. So how do you actually productionise a Databricks App? How do you handle security? How do you do state management, at scale, without building out a whole Azure app service?

This session walks through what changes when you build a real, stateful, multi-user app on Databricks, and how Lakebase rewrites the architecture you'd otherwise reach for. We start with what Lakebase actually is (Postgres-based OLTP that lives inside your workspace), what it changes about app design, and where it sits in relation to Unity Catalog, SQL Warehouse, and Model Serving. Then we walk a real production app: an MDM platform we built that lets data stewards concurrently manage, match, and merge master data records at scale using Lakebase for the OLTP edit layer and session state, SQL Warehouse for the analytical views, and Model Serving as the inference backbone. We cover the architectural decisions, the security and sync model between Lakebase and UC, the gotchas we hit, and what we'd do differently knowing what we now know.

For data engineering leads, architects, and senior practitioners building (or being asked to build) applications on Databricks who suspect the demo pattern stops short of production reality. You'll leave with a clear-eyed view of what Lakebase actually changes and an architectural blueprint for stateful, multi-user apps on the lakehouse.