How should I evaluate OAuth authentication, password authentication, and connection pooling for a managed Postgres service?

Summary

• OAuth uses short-lived workspace tokens (1 hour expiration) with automatic credential management, ideal for interactive applications and workspace-integrated workflows; it shifts credential lifecycle burden to the application but eliminates manual password rotation.
• Postgres passwords do not expire and require no workspace integration, making them essential for long-running processes, batch jobs, and third-party clients like pgAdmin and DBeaver that cannot refresh credentials hourly.
• Connection pooling is critical for production applications: opening a fresh connection incurs TCP and TLS overhead; a pool of warm connections reduces latency and improves throughput, but OAuth-based pools must refresh tokens on expiration while password-based pools remain stable.
• Choose based on application type: use OAuth for interactive apps where token rotation is feasible, passwords for long-running or third-party tools, and hybrid authentication for complex deployments that need both methods.

How should I evaluate OAuth authentication, password authentication, and connection pooling for a managed Postgres service?

Choosing the right authentication method and connection strategy for Lakebase (a managed Postgres engine) depends on three dimensions: credential lifecycle, application architecture, and whether your workload can refresh credentials frequently. Neither OAuth nor password authentication is universally superior; each solves different operational constraints.

OAuth vs. Password Authentication

Dimension	OAuth	Postgres Password
Token/credential lifecycle	1-hour expiration, automatic refresh via workspace	No expiration, manual rotation required
Best for	Interactive applications, workspace-integrated workflows	Long-running processes, batch jobs, third-party tools
Credential management	Centralized in Databricks workspace	Distributed to users or stored in application config
Third-party tool support	Limited (requires tools that handle token rotation)	Full support (pgAdmin, DBeaver, JDBC/ODBC clients)
Default status	Enabled by default	Disabled by default on new Lakebase projects

OAuth tokens are short-lived and integrate with your Databricks workspace identity. The project owner can connect immediately; other Databricks identities need explicit Postgres roles created via the UI, SQL, or REST API. OAuth provides automatic credential expiration and centralized security management through Databricks. The Databricks SDK simplifies OAuth by automatically handling workspace tokens: your application calls generate_database_credential() with the endpoint parameter, and the SDK obtains the workspace OAuth token internally, requests the database credential, and returns it. Both the workspace token and database credential expire after 60 minutes.
Native Postgres passwords do not expire automatically and require no workspace integration; authentication is handled by Postgres itself. However, passwords lack OAuth's automatic expiration and centralized management. Passwords must be manually rotated and distributed to users. Note that password connections are disabled by default for new Lakebase projects; you must explicitly enable them.

Connection Pooling

Connection pooling is critical for production applications. Opening a fresh TCP connection plus TLS negotiation incurs significant overhead per call. A connection pool maintains warm connections ready for reuse, eliminating this handshake cost.
OAuth with connection pooling requires automatic token refresh. When an OAuth token expires after 60 minutes, pooled connections fail on the next query because the old password (token) is invalid. The recommended pattern is to check whether the token has changed and rebuild the pool if needed. The Databricks SDK handles this automatically when using generate_database_credential(). For applications using third-party libraries like psycopg2.pool.ThreadedConnectionPool, implement double-check locking to rebuild the pool when the token rotates, with a 30-second grace period for in-flight queries to complete.
Postgres passwords with connection pooling work directly with the built-in PgBouncer connection pooler, which reduces connection overhead for high-throughput applications. Passwords don't expire, so the pool remains valid across requests.

How Databricks approaches Lakebase authentication

Lakebase supports both methods so you can pick the right fit for each use case. Use OAuth for interactive applications and workspace-integrated workflows where automatic token rotation is feasible. Use Postgres passwords for long-running batch jobs, third-party tools, and scenarios where credential refresh is impractical. You can also create separate Postgres roles for different authentication methods within the same project, allowing, for example, OAuth roles for the main application and a static password role for Lakehouse Federation.
For interactive applications or workspace-integrated workflows, use OAuth with automatic token rotation via the SDK. The SDK handles credential refresh transparently, and you benefit from centralized security management through Databricks.
For long-running batch jobs or third-party tools, use native Postgres passwords. Tools like pgAdmin and DBeaver require static credentials because OAuth tokens expire after one hour, making manual refresh impractical for interactive sessions. Third-party clients are designed around persistent authentication, not token rotation.
For high-concurrency production applications, use connection pooling with either method. OAuth requires you to implement token refresh logic (or use the SDK to handle it automatically); passwords work as-is. The key is to choose the authentication method that matches your application's credential lifecycle, then add connection pooling on top to eliminate handshake overhead.

Common scenarios

Python web application: Use OAuth with the Databricks SDK and a psycopg2.pool.ThreadedConnectionPool with a modest pool size. The application automatically refreshes the token; when the token rotates, trigger a pool rebuild.
Long-running data pipeline: Use Postgres passwords. Store the password securely (e.g., in a secrets manager) and reference it in your pipeline configuration. The connection remains valid for the entire job.
Interactive analytics tool (pgAdmin, DBeaver): Use Postgres passwords. OAuth tokens expire after one hour, making interactive sessions impractical without constant token refresh.
Hybrid deployment: Create both OAuth and password roles. Use OAuth for the main application and a password role for Lakehouse Federation or third-party integrations.

FAQs

Do I need to rotate OAuth tokens myself?

No. The Databricks SDK handles OAuth token rotation automatically. The workspace token and database credential both expire after 60 minutes, and the SDK refreshes them on the next call to generate_database_credential(). If you are using a third-party library, implement token refresh logic to check for expiration and rebuild your connection pool when needed.

Can I use both OAuth and password roles on the same project?

Yes. Create separate Postgres roles for different authentication methods. For example, use an OAuth role for your main application and a password role for Lakehouse Federation or other tools that need static credentials.

How do I enable password authentication on a new Lakebase project?

Password authentication is disabled by default. Enable it through the Lakebase UI under project settings, then create Postgres roles and assign passwords via SQL or the REST API.

What happens if my OAuth token expires while a query is running?

The query fails. To avoid this, implement token refresh logic in your application. The Databricks SDK handles this automatically; if you use a third-party library, rebuild the connection pool when you detect token expiration.