Skip to content

SYSTEM Cited by 1 source

Databricks Postgres CLI

Databricks Postgres CLI is the databricks postgres ... sub-command family inside the broader Databricks CLI — specifically the intended auth path for applications + CI talking to Lakebase.

Minimum viable framing

Lakebase rejects classic Databricks Personal Access Tokens (PATs) and expects an OAuth JWT instead (see concepts/oauth-jwt-short-lived-credential). The CLI command that mints such a JWT is:

databricks postgres generate-database-credential

It produces a scoped, short-lived JWT for a specific endpoint — this is "the intended approach for apps and CI" per the 2026-04-30 Thoughtworks POC. Applications call the command on each credential cycle, capture the JWT into their environment / config, and use it as the password (or bearer) value when opening a Postgres connection to Lakebase.

Typical usage shapes

Production / CI: call the command inside the application's credential-loading path; cache the JWT for its TTL; refresh before expiration.

POC / quick integration: wrap the command in a cron script that rewrites an env var or a .env file. The 2026-04-30 Backstage POC used a 50-minute cadence to refresh DATABRICKS_TOKEN — a pragmatic workaround for apps that don't natively understand short-lived-credential semantics. Canonical patterns/credential-refresh-cron-as-auth-compat-shim.

Why the CLI route exists

Lakebase's auth story is structurally different from Databricks workspace APIs — the workspace control plane accepts PATs (which can be long-lived and scope-broad), but the Lakebase data plane enforces the short-lived-JWT posture so that a leaked token has a bounded blast radius + bounded exposure window. The CLI is the bridge: it takes the caller's Databricks workspace authentication (PAT, OAuth session, or service principal) and issues a per-endpoint database-credential-JWT with much tighter scope.

What's not disclosed

  • Exact JWT TTL — The POC refreshes every 50 minutes; the actual JWT lifetime at the time of that post is not documented in the ingested sources. The 50-minute refresh is a "safely under the TTL" choice by Thoughtworks.
  • Whether the CLI can mint multiple endpoints in one invocation (e.g. for multi-region or multi-database Lakebase deployments).
  • SDK equivalents — whether the Databricks Python / Go / Java SDKs provide the same generate-database-credential primitive in-process (removing the need to shell out to the CLI).
  • Audit trail — whether every generated credential is logged in Unity Catalog or some audit surface.

Seen in

  • sources/2026-04-30-databricks-backstage-with-lakebase — canonical wiki introduction. Thoughtworks uses databricks postgres generate-database-credential inside a 50-minute cron to supply short-lived JWTs to Backstage, which expects a long-lived credential in its app-config.yaml. Verbatim: "The CLI provides databricks postgres generate-database-credential which generates a scoped, short-lived JWT for a specific endpoint, the intended approach for apps and CI." Establishes the CLI as the Lakebase auth path at POC altitude.
Last updated · 439 distilled / 1,268 read