Building applications on Lakebase: Postgres, Databricks Apps and AI in one place

Building applications on Lakebase

The first session of the Gilbert Databricks User Group, on 18 September 2026 at the TechFabric office in Gilbert.

Four things, live

The running order, each with the script that ran it: PostgreSQL with Databricks identity, safe branching and recovery, a secure Data API, and lakehouse and application data together.

One database, two neighbourhoods

Lakebase is a managed Postgres inside a Databricks project. Applications connect to it as ordinary Postgres, Unity Catalog governs it, curated Delta snapshots land in a lakehouse schema, and every application write streams back out.

PostgreSQL with Databricks identity

Section one of four. Existing tools connect unchanged, and tokens replace passwords.

Where the password would have been

A workspace login through databricks psql and an application's client credentials mint the same thing, a one-hour OAuth token. Postgres sees a role, and ordinary GRANT decides the rest.

Nothing to rewrite

It is ordinary PostgreSQL: foreign keys, check constraints, joins, and any client or ORM connecting unmodified. The project sets enable_pg_native_login to false, so there are no database passwords to rotate or to leak.

What scale-to-zero costs you

Measured on this project rather than read off a datasheet. The first query against an idle endpoint took 2,979 ms against 1,650 ms warm, so about 1.3 seconds of a cold query is the endpoint waking. Five idle minutes and it scales back to zero on its own.

Safe branching and recovery

Section two of four. An isolated copy in seconds, and a way back after a bad update.

A database in four seconds

create-branch returned READY in 4.5 seconds with its own read-write endpoint. logical_size_bytes starts at zero because the pages are shared copy-on-write with the parent, so only the branch's own writes add bytes.

The same question, two answers

One fingerprint query run against both branches after a schema change, a price change and a destructive DELETE on the branch alone. Production never saw any of it.

The UPDATE that lost its WHERE

Recovery is a branch at a timestamp. source_branch_time snaps to the last committed write at or before the moment you ask for, and source_branch_lsn is the exact alternative. Repairing from it is ordinary Postgres, a COPY out and an UPDATE ... FROM back in.

What the script is honest about

history_retention_duration was seven days on this project, and past it there is no moment left to branch from. The repair assumes nothing else is writing, which is true of a demo and worth saying out loud before running the same shape against a live database.

A secure Data API

Section three of four. REST over Postgres, with no API service to build and host.

From the browser to the policy

The only server-side code is the token exchange, and the browser never holds the secret. Because the Data API runs each request as the caller's identity, GRANT and row-level security are the whole authorization model.

The URL is the query

Filter and order are query parameters, foreign keys come back as embedded objects with no join written anywhere, counts and pagination are headers, and a write is a POST to the same URL. Responses ran 384 to 542 ms.

One policy, three answers

One row-level security policy on demo_app.orders, tested against the role each token became. The owner sees every status over psql, the service principal gets an empty array for rows it may not read, and posting a cancelled order comes back 403 with 42501, because the policy refuses to create what it would hide.

Lakehouse and application data together

Section four of four. One governance model over Delta and Postgres, and traffic both ways.

In as a snapshot, out as history

Two managed pipelines and no reverse-ETL code. The synced copy lives in its own lakehouse schema so the change feed on demo_app does not replicate straight back out, and application writes reach Delta in 10 to 15 seconds.

Registered, then synced

postgres create-catalog took 5.7 seconds and makes the database a Unity Catalog catalog, with a SQL warehouse reading live Postgres rows in place and no copy. create-synced-table in SNAPSHOT mode was online 51 seconds after the call, and a re-snapshot runs about 33 seconds.

Every write is a Delta record

One order's insert, update and delete as they land in the change data feed, with the transaction id on every row. REPLICA IDENTITY FULL has to be set before the feed is enabled, because a table without it is SKIPPED and flipping it afterwards is not reliably picked up.

Questions

Where the session ended, and where the group picks up: the Gilbert Databricks User Group meets at the TechFabric office in Gilbert.