When your application maintains thousands of concurrent connections or creates connections at high frequency, PolarDB for PostgreSQL (Compatible with Oracle) is under pressure: each connection requires a dedicated backend process, and the process overhead degrades performance. The transaction-level connection pool feature routes all client traffic through PolarProxy, allowing multiple frontend connections to share one backend connection. This significantly reduces backend process count and improves database throughput.
Prerequisites
Before you begin, ensure that you have:
PolarProxy V2.3.46 or later
How it works
PolarProxy sits between your application and the backend database. Instead of creating a backend connection for every client connection, PolarProxy maintains a pool of backend connections and reuses them across transactions:
A client connects to PolarProxy.
PolarProxy checks the pool for an idle backend connection that matches the request's
user,dbname, and system variable settings.If a matching idle connection exists, PolarProxy reuses it. If not, PolarProxy opens a new backend connection.
After the transaction commits, the connection returns to the pool and becomes available to the next request.
This multiplexing lets you maintain thousands of client-to-PolarProxy connections while PolarProxy opens only dozens or hundreds of connections to the backend database.
PolarProxy does not limit the number of client connections. The maximum number of connections to a PolarDB cluster endpoint depends on the compute node specifications of the backend database. When transaction-level connection pooling is disabled, the system creates a dedicated connection on the primary node and each read-only node for every client request.
When to use transaction-level connection pooling
Scenario | Use connection pooling? | Reason |
Tens of thousands of concurrent connections | Yes | Pooling reduces the backend connection count significantly |
Serverless workloads that scale horizontally | Yes | Connection count grows linearly with server scale; pooling absorbs the increase |
Small number of connections, mostly long connections | No | Long connections already amortize connection overhead; pooling adds no benefit |
Application already uses its own connection pool | No | A well-established client-side pool achieves the same effect |
For the "Yes" scenarios above, enable transaction-level connection pooling only if your service does not run in scenarios described in the Connection pinning section below.
Enable transaction-level connection pooling
Log on to the PolarDB console.
Click Clusters in the left-side navigation pane. In the upper-left corner of the Clusters page, select the region where the cluster resides.
Find the cluster and click the cluster ID.
In the URL section, click Configuration.
In the Connection Pool section, set Connection Pool to Transaction-level.
Click OK.
Disable transaction-level connection pooling
Log on to the PolarDB console.
Click Clusters in the left-side navigation pane. In the upper-left corner of the Clusters page, select the region where the cluster resides.
Find the cluster and click the cluster ID.
In the URL section, click Configuration.
In the Connection Pool section, set Connection Pool to Disable.
Click OK.
Connection pinning
Some operations cause a backend connection to be pinned — locked to the current client session until the session closes. A pinned connection is not returned to the pool and cannot be reused by other clients.
If your workload frequently triggers pinning, the pool cannot multiplex connections effectively. Review the operations below and consider using a direct connection instead.
Operation | Why it causes pinning |
Execute a | The prepared statement is bound to a specific backend process |
Process packets larger than 16 MB | Large packet handling requires a dedicated connection state |
Enter copy mode |
|
Enter flush mode | Flush mode requires persistent connection state across calls |
Create a temporary table, sequence, or view | These objects are bound to a specific backend session |
Use a transaction | An open transaction holds the connection until |
Declare a cursor | A cursor's result set lives on the backend process that opened it |
Specify the | The |
Because backend connections are shared across clients, thepidreturned bySELECT pg_backend_pid()may change between transactions. Similarly, the client IP address and port shown inpg_stat_activityand SQL Explorer may differ from the actual client address.