Databricks Lakebase Postgres: projects, scaling, connectivity, Lakebase synced tables, and Data API. Use when asked about Lakebase databases, OLTP storage, or connecting apps to Postgres on Databricks.

Lakebase Postgres Autoscaling FIRST : Use the parent databricks core skill for CLI basics, authentication, and profile selection. Lakebase is Databricks' serverless Postgres compatible database, available on both AWS and Azure (GA). It provides fully managed OLTP storage with autoscaling, branching, and scale to zero. Provisioned Lakebase no longer exists — never create it. The old Provisioned tier (static, non scalable Postgres; databricks database CLI / w.database SDK) is being migrated to Autoscaling over summer 2026, with no customer action required. Lakebase today is Autoscaling only ( databricks postgres / w.postgres ). Do not attempt to create Provisioned instances; if a user asks for one, tell them Provisioned instances don't exist anymore and point them to Autoscaling. Treat the legacy database resource key in app configs as retired — migrate to the postgres resource key. For the legacy DAB synced database tables resource, use the databricks postgres create synced table CLI flow instead (see the Common Issues row and references/synced tables.md ). For context when reading older configs or docs, here is how the retired Provisioned tier maps to Autoscaling: Aspect Provisioned (retired) Autoscaling (current) CLI group databricks database databricks postgres Top level resource Instance Project Capacity CU 1–CU 8 (16 GB/CU) 0.5–112 CU (2 GB/CU) Branching Not supported Full support Scale to zero Not supported Configurable HA Readable secondaries 1–3 secondaries + read replicas Data API Not available PostgREST HTTP API Cloud AWS only AWS and Azure Compliance: Supports HIPAA, C5, TISAX, or None. Capabilities Project lifecycle create, update, delete Lakebase Postgres Autoscaling projects Branching copy on write branches with TTL, point in time recovery, and reset Compute scaling autoscale 0.5 32 CU, fixed 36 112 CU, scale to zero High availability 1 primary + 1 3 secondaries, automatic failover PostgreSQL connectivity OAuth token refresh, connection pooling, SSL Data API PostgREST compatible HTTP CRUD (Autoscaling only) Lakebase synced tables sync Unity Catalog Delta tables into Postgres (previously known as Reverse ETL) Databricks App integration scaffold apps with Lakebase feature, deploy first workflow Cloud support AWS and Azure (GA) Reference docs: [computes and scaling.md](references/computes and scaling.md) — Sizing, endpoint management, scale to zero, HA [connectivity.md](references/connectivity.md) — Connection patterns, token refresh, Data API [synced tables.md](references/synced tables.md) — Lakebase synced tables, data type mapping, capacity planning [lakehouse sync.md](references/lakehouse sync.md) — CDC from Lakebase Postgres to Unity Catalog Delta tables ( UI only — cannot be configured via CLI or API) [pgvector.md](references/pgvector.md) — Vector similarity search with pgvector extension [off platform.md](references/off platform.md) — Off platform Lakebase (NOT Databricks Apps): external Node.js apps connecting via @databricks/lakebase , env management, token refresh, Drizzle ORM Resource Hierarchy Project : Top level container. Creating one auto provisions a production branch and a primary read write endpoint. Branch : Isolated database environment sharing storage with parent (copy on write). States: READY , ARCHIVED . Endpoint (called Compute in UI): Compute resource powering a branch. Types: ENDPOINT TYPE READ WRITE , ENDPOINT TYPE READ ONLY . Database : Standard Postgres database within a branch. Default: databricks postgres . Role : Postgres role within a branch. Resource Name Formats Resource Format Project projects/{project id} Branch projects/{project id}/branches/{branch id} Endpoint projects/{project id}/branches/{branch id}/endpoints/{endpoint id} Database projects/{project id}/branches/{branch id}/databases/{database id} All IDs: 1 63 characters, start with lowercase letter, lowercase letters/numbers/hyphens only (RFC 1123). CLI Discovery ALWAYS Do This First Note: "Lakebase" is the product name; the CLI command group is postgres . All commands use databricks postgres ... . Do NOT guess command syntax. Discover available commands dynamically: Create a Project First decide: reuse or create. When building or attaching to an app, ask the user whether to reuse an existing project/branch/database — list them with databricks postgres list projects (then list branches / list databases ), let the user pick, and confirm which schema the app will own — or create a new project. Only skip listing and create directly when the user explicitly asked for a brand new project. Auto creates: production branch + primary read write endpoint (1 CU min/max, scale to zero). Long running operation; CLI waits by default. Use no wait to return immediately. After creation, verify: Extract connection values from JSON output: Value JSON path Used for Endpoint host status.hosts.host PGHOST , lakebase.postgres.host Endpoint resource path name LAKEBASE ENDPOINT , lakebase.postgres.endpointPath Database resource path name lakebase.postgres.database PostgreSQL database name status.postgres database PGDATABASE , lakebase.postgres.databaseName Updating a Project Deleting a Project WARNING: Permanent deletes all branches, computes, databases, roles, and data. Do not delete without explicit user permission. Autoscaling Endpoints use compute units (CU) (~2 GB RAM per CU). Range: 0.5 32 CU (dynamic), 36 112 CU (fixed). Scale to zero enabled by default (5 min timeout). See [computes and scaling.md](references/computes and scaling.md) for sizing tables, endpoint CRUD, and configuration details. Branches Branches are copy on write snapshots. Use for testing schema migrations, trying queries, or previewing data changes without affecting production. Branches require an expiration policy: "no expiry": true for permanent, or "ttl": "<seconds s" (max 30 days). Limits: 10 unarchived branches per project. 8 TB logical data per branch. 1,000 projects per workspace. Use Case TTL CI/CD environments 2 4 hours ( "ttl": "14400s" ) Demos 24 48 hours ( "ttl": "172800s" ) Feature development 1 7 days ( "ttl": "604800s" ) Long term testing Up to 30 days ( "ttl": "2592000s" ) Point in time branching: Create from a past state (within restore window) for recovery. The time specification fields live inside the json spec ( spec.source branch time , spec.source branch lsn ), not as top level create branch flags. Reset: Replaces branch data and schema with the latest from its parent. Local changes are lost. Root branches and branches with children cannot be reset; protected branches ( spec.is protected ) cannot be reset either. Reset is UI only — there is no databricks postgres reset branch CLI command and no API/SDK method for it. In the Lakebase App, go to the project's Branches page, click the menu next to the branch, and select Reset from parent . CLI workarounds: Delete + recreate: delete branch , then create branch with spec.source branch set to the parent (unprotect via update branch first if protected). Point in time: create branch with spec.source branch time or spec.source branch lsn . Timestamp based reset is not supported; use PITR branching instead. Delete: Protected branches must be unprotected first ( update branch to set spec.is protected to false ). Cannot delete branches with children. Never delete the production branch. What's Next Build a Databricks App After creating a project, scaffold a connected Databricks App: For the full app workflow, use the databricks apps skill. Attach Lakebase to an existing app apps init features lakebase (above) wires the database at scaffold time. To attach a project to an existing app, update its resources. Use the postgres resource key — its fields are branch + database (full resource paths from the table above). The legacy database key ( instance name + database name ) is deprecated; using it fails with Database instance <name does not exist . Get the exact paths from list branches / list databases (the DB name is often hyphenated, e.g. databricks postgres ). Update the app's resources with databricks apps create update — the method to use for any app (the older databricks apps update is legacy and can't change resources for an app in a space). update mask=resources replaces the whole resources array, so read the app's current resources and merge the new one in (or you'll detach the rest). Pass everything in json ; only APP NAME is positional: Confirm the branch/database with the user — don't default to production silently. The app's service principal must be able to create and own the schema(s) it uses there, so avoid a branch/database where those schema names are already owned by a user (the SP will hit permission denied … 42501 ) — a fresh/dedicated branch, or a new app owned schema, is cleanest. See Schema Permissions for Deployed Apps below for the full ownership model. Schema Permissions for Deployed Apps The app's Service Principal has CAN CONNECT AND CREATE it can create new objects but cannot access existing schemas . The SP must create the schema to become its owner. ALWAYS deploy the app before running it locally. This is the 1 source of Lakebase permission errors. Correct workflow: 1. Deploy first : databricks apps deploy <APP NAME profile <PROFILE 2. Grant local access (if needed) : assign databricks superuser via UI (project creators already have access) 3. Develop locally : your credentials get DML access to SP owned schemas If you already ran locally first and hit permission denied : the schema is owned by your credentials, not the SP. Do NOT drop the schema without asking the user dropping it deletes all data. Ask the user to choose: (A) Drop and redeploy: databricks psql project <PROJECT ID c "DROP SCHEMA IF EXISTS <SCHEMA NAME CASCADE;" , then databricks apps deploy from the app directory. The SP recreates the schema on startup. (B) Export first, then drop and redeploy: export via pg dump (use connection details from databricks postgres get endpoint ; see Other Workflows below for HOST and TOKEN) or copy tables to a temp schema using databricks psql project <PROJECT ID , then do option A. After the SP recreates the schema on redeploy, restore with pg restore or re INSERT from the temp schema. Other Workflows Run SQL against Lakebase (GRANT, CREATE INDEX, etc.): Note: generate database credential requires the endpoint resource path ( .../endpoints/<ENDPOINT ID ), not a database or branch path. Scriptable version (single copy paste, useful for agents): Grant app SP access to synced tables (run as project owner after sync is ONLINE and app is deployed): For least privilege, consider syncing into a dedicated schema instead of public so the grant is scoped to synced data only. Get SP client ID: databricks apps get <APP NAME profile <PROFILE → service principal client id field. Data API: PostgREST compatible HTTP CRUD on Postgres tables. See [connectivity.md](references/connectivity.md). Synced Tables: Sync Delta tables into Lakebase. See [synced tables.md](references/synced tables.md). PostgreSQL Extensions Lakebase supports PostgreSQL extensions (e.g., pgvector for vector embeddings, pg stat statements for query statistics). See the [full list of supported extensions](https://docs.databricks.com/aws/en/oltp/projects/extensions). For vector embeddings with pgvect

databricks-lakebase