Skip to content

PATTERN Cited by 1 source

Native Postgres roles for non-Databricks-aware partners

Pattern. When integrating Lakebase with a non-Databricks-aware partner system that connects via standard Postgres protocol, fall back to native Postgres password roles instead of OAuth roles, because OAuth's hourly token rotation isn't compatible with partner systems that expect long-lived database credentials.

The pattern is disclosed in the 2026-05-20 marketing-campaigns post, applied to SAP Engagement Cloud:

"Lakebase supports OAuth roles for Databricks identities and Native Postgres password roles. Because Engagement Cloud can't handle the hourly token rotation happening for OAuth roles, we will use native Postgres roles."

The architectural problem

OAuth + short-lived JWT is the modern security default for everything Lakebase talks to natively (Databricks identities, Databricks Apps, Databricks-native workflows). The hourly rotation is a feature — stolen tokens are invalidated within an hour.

But partner systems built outside the Databricks ecosystem typically:

  • Connect via standard Postgres wire protocol with a static username + password.
  • Have no notion of token rotation; they treat the credential as long-lived.
  • Have no integration hooks to refresh credentials on a schedule.

When you point such a partner system at an OAuth-roled Lakebase user, every hour the credential expires and the partner's connection breaks until manual re-credentialing.

The escape hatch

Lakebase exposes native Postgres password roles as the explicit answer. From the post:

"Postgres roles can be created in various ways; we will use the Lakebase UI to generate a high-entropy password. Capture the password immediately and store it in a secret manager. We recommend rotating passwords by generating new ones on a regular schedule."

The architectural shape:

Property OAuth roles Native Postgres password roles
Identity Databricks identity Postgres role (independent)
Rotation Automatic, hourly Manual / operationally scheduled
Credential lifetime 1 hour Indefinite (until rotated)
Use case Databricks-native workloads Non-Databricks-aware partners
Security tradeoff Auto-bounded blast radius Operational discipline required

Operational implications

The pattern shifts the security tradeoff from "the system handles it" to "the operator handles it":

  1. Generate a high-entropy password via the Lakebase UI.
  2. Capture the password immediately (the UI shows it once).
  3. Store in a secret manager (the post emphasises this).
  4. Configure the partner system with the password.
  5. Rotate on a regular schedule by generating new passwords periodically.

The "regular schedule" is left to operator judgement — the post doesn't quantify it. In practice, this should align with the partner system's capability for credential rotation (many enterprise systems support scheduled credential rotation via secret managers like AWS Secrets Manager or HashiCorp Vault).

When to apply

Use native Postgres password roles when all of these are true:

  • The consumer is not a Databricks-native workload.
  • The consumer's connection layer expects long-lived Postgres credentials.
  • The consumer cannot accommodate hourly token rotation.

Use OAuth roles when:

  • The consumer is a Databricks-native workload (Apps, notebooks, jobs).
  • The consumer's auth layer can integrate with Databricks identity.

Generalisation

The pattern is a specific instance of a broader shape: when a modern security default (short-lived rotated credentials) hits a legacy partner system that can't accommodate it, provide a well-marked legacy escape hatch with explicit operational guidance to maintain security through alternative means.

Sibling patterns:

  • patterns/credential-refresh-cron-as-auth-compat-shim — earlier Lakebase-disclosed pattern for refreshing short-lived credentials on a schedule for systems that can accept new tokens but lack OAuth integration.
  • Database systems exposing both IAM-auth and password-auth modes (AWS RDS, Azure Database for PostgreSQL).
  • TLS systems exposing both mTLS and shared-secret auth modes.

Trade-offs

Pro Con
Unblocks integration with non-Databricks partners Loses OAuth's automatic rotation security property
Operationally simple — works with any Postgres-compatible system Requires explicit operational discipline for rotation
Compatible with secret-manager-driven credential rotation The hourly-bounded blast-radius property is gone

Constraints (disclosed)

  • Partner systems must accept the trust chain. Lakebase uses Let's Encrypt for TLS; partner systems requiring a CA certificate (like SAP Engagement Cloud) must trust ISRG Root X1.
  • Password rotation is on the operator. The post recommends "rotating passwords by generating new ones on a regular schedule" — this is operational guidance, not enforced policy.

Seen in

Last updated · 542 distilled / 1,571 read