YugabyteDB YSQL and JDBC driver: interaction of expired VALID UNTIL roles with connection pooling

Interaction of VALID UNTIL with Pooled Connections

In YugabyteDB YSQL, the VALID UNTIL clause is evaluated during the authentication handshake. Once a connection is established and the session is authorized, the server does not proactively terminate that session simply because the role's validity period expires.

Behavioral Analysis

• Existing Pooled Connections: If a JDBC connection pool (such as HikariCP) establishes a connection before the VALID UNTIL timestamp, that connection remains usable for queries even after the role expires. The server treats the session as already authenticated.
• New Connection Requests: Any attempt to create a new connection after the expiration timestamp will be rejected by the yb-tserver during the login phase.
• The Role of --ysql_authentication_timeout: This flag controls the maximum time allowed for the authentication process to complete. It does not act as a session TTL or a heartbeat check for role validity; it only influences the window during which the initial handshake must occur.
• JDBC Driver Caching: Standard PostgreSQL and YugabyteDB JDBC drivers do not cache credentials in a way that bypasses server-side checks for new connections. However, because the pool maintains the TCP session, the driver never triggers a new authentication request, effectively bypassing the expiration check for the life of that specific connection.

Verification Steps

To verify this behavior in your environment, execute the following sequence:

1. Create a role with a short expiration window: CREATE ROLE test_user WITH LOGIN PASSWORD 'password' VALID UNTIL '2026-10-10 10:00:00';
2. Establish a connection via your JDBC pool before the expiration time.
3. Wait for the timestamp to pass.
4. Execute a SELECT 1; using the existing pooled connection. It should succeed.
5. Force the pool to create a new connection (e.g., by restarting the app or reducing pool size). This attempt should fail with an authentication error.

Assumptions and Constraints

This analysis assumes standard YSQL authentication flows. We assume the use of a connection pool that maintains long-lived TCP sessions. If your environment uses a proxy or load balancer that terminates idle connections, the "window of usability" for an expired role will be limited to the proxy's idle timeout.

Missing Diagnostic Detail: Are you using an external identity provider (LDAP/Active Directory) via YugabyteDB, or are you using internal YSQL roles? External providers may have different session revocation behaviors.