# Building applications on Lakebase: Postgres, Databricks Apps and AI in one place > Preetham Reddy built an app live on Lakebase, with an AI agent that sees only what its user may see. It's how we'd give the business an app on its own data, with Postgres beside the analytics and no copy job between them. Organised by: Gilbert Databricks User Group When: 2026-09-18T18:00:00-07:00 to 2026-09-18T20:00:00-07:00 (America/Phoenix) Where: TechFabric, EZ Spaces Coworking, 1530 E Williams Field Rd, Ste 201, Gilbert, AZ 85295 Format: in-person Speaking: Preetham Reddy, Founder and CEO, TechFabric Slides: https://www.techfabric.com/blog-media/events/building-applications-on-lakebase/deck.pdf Code: https://github.com/Fabric-Pro/fabric-databricks-usergroup Register: https://usergroups.databricks.com/events/details/databricks-user-groups-gilbert-databricks-user-group-presents-building-applications-on-lakebase-postgres-databricks-apps-and-ai-in-one-place/ Canonical: https://www.techfabric.com/events/building-applications-on-lakebase --- ## What happened The first Gilbert Databricks User Group session, at the TechFabric office, built an application on Lakebase live from a script. Every number on the slides was measured in the room that evening. Branching the whole database reached READY in 4.5 seconds. A cold query cost 2,979 ms against 1,650 ms warm, a synced table came online 51 seconds after the call, and writes from the app reached Delta inside 10 to 15 seconds. ## The slides **1. Building applications on Lakebase** The first session of the Gilbert Databricks User Group, on 18 September 2026 at the TechFabric office in Gilbert. **2. 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. **3. 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 **5. 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. **6. 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. **7. 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 **9. 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. **10. 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. **11. 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. **12. 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 **14. 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. **15. 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. **16. 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 **18. 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. **19. 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. **20. 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. **21. Questions** Where the session ended, and where the group picks up: the Gilbert Databricks User Group meets at the TechFabric office in Gilbert. The deck has its own page at https://www.techfabric.com/events/building-applications-on-lakebase/slides. ## About this session Nobody typed a database password all evening. This project sets `enable_pg_native_login` to false, so there isn't one to type, and a person at `psql` and an application holding client credentials both arrive as the same one-hour OAuth token. Lakebase is managed Postgres inside a Databricks project, with lakehouse tables synced into it and the operational data sitting beside the analytics under one set of permissions. That collapses a stack most teams run as three systems and two copy jobs. We built an application on it live, from a script, and worked through four parts of it: signing in with Databricks identity, branching and recovery, a Data API straight over Postgres, and moving data between the lakehouse and the application in both directions. ## PostgreSQL with Databricks identity The schema is ordinary Postgres, foreign keys and check constraints and all, and every client we pointed at it connected unmodified. Postgres reads the token as a role, so `GRANT` decides the rest exactly as it always has, and the credential you would normally be rotating and eventually leaking isn't there to manage. Scale-to-zero is the other thing people want a number for. Cold, the first query took 2,979 ms. Warm it was 1,650 ms, so roughly 1.3 seconds of that is the endpoint waking up, and five idle minutes later it goes back to zero on its own. ## Safe branching and recovery `create-branch` came back READY in 4.5 seconds with its own read-write endpoint and `logical_size_bytes` at zero. Pages are shared copy-on-write with the parent, so a branch costs you only what you write into it. Then we broke things on it. One fingerprint query run against both branches showed a schema change, a price change and a `DELETE` that production never saw. Recovery is the same trick pointed at a clock. `source_branch_time` snaps to the last committed write at or before the moment you name, `source_branch_lsn` is the exact version of the same idea, and we used it on an `UPDATE` that had lost its `WHERE`. Repairing from there is ordinary Postgres, a `COPY` out and an `UPDATE ... FROM` back in. ## A secure Data API REST straight over Postgres, with nothing to build or host in between. The only server-side code we wrote was the token exchange, so the browser never held the secret. Filters and ordering ride in as query parameters, foreign keys come back as embedded objects with no join written anywhere, and responses ran 384 to 542 ms. Every request runs as whoever is calling, which makes `GRANT` and row-level security the entire authorization model. One policy on `demo_app.orders` gave three callers three different answers. The owner saw every status over `psql`, the service principal got an empty array where it wasn't allowed to read, and posting a cancelled order came back 403 with `42501`, because a policy that would hide a row won't let you create it either. ## Lakehouse and application data together `postgres create-catalog` took 5.7 seconds and turns the database into a Unity Catalog catalog, after which a SQL warehouse reads live Postgres rows in place with no copy anywhere. Where we wanted a curated Delta table instead, `create-synced-table` in SNAPSHOT mode came online 51 seconds after the call and re-snapshotting runs about 33 seconds. Traffic goes the other way too. Writes from the application reach Delta through the change data feed in 10 to 15 seconds with the transaction id on every row, and the synced copy lives in its own lakehouse schema so the feed on `demo_app` doesn't replicate straight back out again. ## Where the seams are `history_retention_duration` was seven days here, and past that there's no moment left to branch from, so it's worth settling on the number before somebody needs it. The repair we ran assumes nothing else is writing, which is true of a demo and won't be true of your production database. `REPLICA IDENTITY FULL` has to be set before you enable the change data feed, because a table without it gets skipped, and flipping it afterwards isn't reliably picked up. ## Who was in the room Application developers, data engineers and architects from around the Phoenix metro, a good number with laptops open, following the script as it ran. Some are already on Databricks and some are still deciding. Questions ran about half an hour at the end. The group meets at the TechFabric office in Gilbert.