FAQ about the database proxy

A database proxy is a network proxy that sits between your application and your RDS instance, forwarding all requests. It provides read/write splitting and transaction splitting automatically, without changes to your application code. The proxy runs in a high availability architecture, so it doesn't introduce a single point of failure.

For an overview of the feature, see What are database proxies?

• General-purpose: Shared physical CPU resources, provided free of charge. Maximum specification: 16 CPU cores (8 proxies).

• Dedicated: Exclusively allocated physical CPU resources, billed on a pay-as-you-go basis. Maximum specification: 32 CPU cores (16 proxies).

Choose dedicated proxies when you need stable, predictable performance and your workload cannot tolerate resource contention from neighboring tenants.

For pricing details, see Billing rules for the database proxy feature.

Each proxy unit contributes 2 CPU cores. The total specification is:

Proxy specification = 2 CPU cores × number of database proxies

For example, 3 proxies give you a 6-core specification (2 × 3 = 6).

To size your proxies correctly, use these formulas:

Example: A primary instance with 8 CPU cores and a read-only instance with 4 CPU cores needs (8 + 4) / 8 = 1.5, rounded up to 2 dedicated proxies, for a specification of 4 CPU cores.

No. The number of proxy endpoints has no effect on proxy performance. Performance depends on:

• Number of read-only instances — more read-only instances handle more read requests.

• Number of proxies — more proxies improve overall throughput.

• Proxy specification — higher specification means more processing capacity.

No, these are independent. Each RDS for PostgreSQL instance with the proxy enabled supports up to 7 database proxy endpoints, regardless of how many proxies you have. Each endpoint can have one internal endpoint and one public endpoint.

For setup instructions, see Create a database proxy endpoint.

No. The proxy operates independently and does not consume the queries per second (QPS) or transactions per second (TPS) of your primary RDS instance.

A regular endpoint forwards all requests to the same RDS instance. A database proxy endpoint automatically routes write requests to the primary RDS instance and read requests to read-only instances based on the SQL statement type. This reduces load on the primary instance without requiring routing logic in your application.

No. The original endpoints of your primary and read-only instances remain available after you enable the database proxy. Continue using them directly if needed.

The proxy runs in a high availability architecture with two primary nodes, balancing connections at a 1:1 ratio. If one node fails, the other takes over immediately and the system automatically triggers a restoration task on the failed node.

No. ApsaraDB RDS for PostgreSQL database proxies do not support connection pooling. The maximum number of connections that can be established to a database proxy is unlimited. The number of connections supported by the proxy is determined by the smaller of the primary instance's connection limit and the read-only instances' connection limit.

For example, if the primary instance supports 1,600 connections and the read-only instances support 800, the proxy supports 800 connections.

For the connection limits of specific instance types, see Instance types for primary ApsaraDB RDS for PostgreSQL instances and Instance types for read-only ApsaraDB RDS for PostgreSQL instances.

Yes. Modify the prefix and port for any database proxy endpoint.

For instructions, see Manage database proxy endpoints.

Add the /*FORCE_MASTER*/ hint to your SQL statement:

/*FORCE_MASTER*/ SELECT * FROM table_name;

To explicitly route a read request to a read-only instance instead, use /*FORCE_SLAVE*/.

Read weight changes apply only to new connections. Existing connections are not re-established and keep the old weights until they disconnect and reconnect. To apply the new weights immediately, close existing connections and let your application reconnect.

The proxy monitors instance health continuously and detects failures within 2 seconds. Once the instance recovers, the proxy resumes routing traffic immediately — your application does not need to reconnect or handle any recovery logic.

On the Database Proxy page, go to the Connection Information section. Find the internal endpoint and move the pointer over the icon in the Internal Endpoint/Port column.