Databricks Pushes Lakebase Postgres as the Backend for Apps and Agents

Databricks is positioning Lakebase Managed Postgres as a managed PostgreSQL backend for web applications and AI agents. Its September 2 developer push centers on a database colocated with the Lakehouse and integrated and secured within the Databricks workspace.

A developer-facing push

The immediate catalyst is Databricks’ September 2 developer promotion of Lakebase. It presents the service as a Postgres database for shipping web apps and agents, provisionable through the command-line interface and queryable from any application. Databricks also highlights autoscaling, scale-to-zero compute and instant database branching.

The product’s application path was already more concrete in Databricks documentation updated August 28. Databricks Apps lets customers build and deploy interactive applications directly in a workspace; adding Lakebase as a resource gives an app a fully managed Postgres backend. The company supplies autoscaling examples in Dash, Flask and Streamlit, using a simple todos application to demonstrate the connection.

How the connection is assembled

Databricks automates the identity handoff when Lakebase is attached to an app. It creates a service principal, a dedicated identity for that app rather than an individual user, then creates a matching Postgres role with database access. Connection details arrive as environment variables, so the template can connect without developers managing credentials or connection strings in code.

A Lakebase project is a managed Postgres instance organized into branches, with a production branch created by default. That gives a team isolated database environments within one project. The application server’s compute is separate from database compute and scales independently, so choosing an app server size does not set the database’s compute size.

Data can stay connected to the lakehouse

By default, an app’s Lakebase data is available through direct Postgres connections. A team can instead register the database in Unity Catalog, Databricks’ catalog layer, and query its transactional tables through Databricks SQL alongside lakehouse data. That registration enables a single query to join app tables with Delta tables, according to the documentation.

The managed route still has operational boundaries. The documented setup requires a workspace with Lakebase and serverless compute enabled, plus permission to create compute resources and apps. Scale-to-zero can also trade idle cost for a pause: Databricks says the first database query after a long idle period may take a few seconds to respond.

The builder’s remaining decisions

Databricks has simplified the path from an application to a database, but it has not removed the design choices around it. Builders still select the Lakebase project, branch and database their app will use, decide whether to expose data only through Postgres or also register it in Unity Catalog, and choose app-server compute independently from the database. That makes Lakebase less a standalone database pitch than a route for keeping application state, app identity and lakehouse analysis inside one workspace.