SSL connections are currently not supported.

Long-running transactions can suspend other sessions assigned to the same backend, as the backend cannot serve another session until the current transaction is complete. It is recommended to avoid such transactions in pooled sessions and set the idle_in_transaction_session_timeout or client_connection_check_interval configuration parameters, so that idle transactions can be terminated by timeout. For databases or users that are likely to run long transactions, you can also use dedicated backends.

The level of the FATAL: connection to client lost error is lowered to ERROR. If such an error is trapped, Postgres Pro will fail to terminate hanging transactions by timeout.

Using prepared transactions (2PC) in pooled sessions is only possible if you ensure that they are completed by the same session that has prepared them, and enable the hold_prepared_transactions configuration parameter to forbid rescheduling the backend to another session until all prepared transactions in the current session are committed or rolled back.

Built-in connection pooler does not support advisory session-level locks (pg_advisory_lock) and returns an error if you try using them.

Modules that maintain the session state internally, such as plantuner, are not guaranteed to work with connection pooling enabled.

Connection pooling is incompatible with the following extensions:

Changing configuration of other sessions as explained in Section 9.26.1 is not allowed if connection pooling is enabled.

Asynchronous notifications are not supported, so you cannot use NOTIFY, LISTEN, and UNLISTEN SQL commands, or the pg_notify function.

When the connection pooler is enabled and serves client sessions, “Smart” shutdown is performed as “Fast”.

1C solutions are not supported as they use their own built-in pooler.

Windows systems are currently not supported.

Closing connections due to idle_session_timeout is not supported when connection pooling is enabled.