When your ApsaraDB RDS for PostgreSQL instance is overloaded by too many connections or read-heavy traffic, a database proxy gives you read/write splitting and transaction splitting to offload requests from the primary instance — without changing your application code.
When to use a database proxy
A database proxy is most useful in these situations:
| Signal | Problem | How a proxy helps |
|---|---|---|
| You see "too many connections" errors | The primary instance is hitting its connection limit | The proxy manages connections centrally, reducing the number of direct connections to the instance |
| CPU or query latency spikes during peak hours | Large numbers of transactional read requests overload the primary | Transaction splitting routes pre-write reads to read-only instances |
| Read throughput exceeds what one instance can handle | A single primary instance can't serve all read traffic | Read/write splitting routes read requests to read-only instances automatically |
| Two applications have different access patterns | A read-only app and a read/write app share the same database system | Bind them to separate proxy endpoints with different attributes to physically isolate them |
Example: A database system has one primary instance and four read-only instances serving two applications. Application A issues only read requests; Application B issues both reads and writes. Configure two proxy endpoints: bind two read-only instances to an endpoint with the Read-only attribute for Application A, and bind the primary instance plus the remaining two read-only instances to an endpoint with the Read/Write attribute for Application B. The two applications are physically isolated within the same database system.
How it works
A database proxy is a network proxy layer that sits between your application and ApsaraDB RDS for PostgreSQL. All application requests pass through it before reaching the database. You connect to your RDS instance through a database proxy endpoint rather than directly to the primary instance.
The proxy inspects each request and routes it based on your configuration:
Write requests go to the primary instance.
Read requests go to read-only instances (when read/write splitting is enabled).
Reads before the first write in a transaction go to read-only instances (transaction splitting, always on).
Key concepts
Database proxy endpoint
Database proxy endpoints are the core of database proxies. Each endpoint has its own connection settings, prefix, and port. Connecting through a proxy endpoint gives you access to read/write splitting, transaction splitting, and simplified connection management.
Each RDS instance supports up to seven database proxy endpoints. For each endpoint, you can apply for one internal endpoint and one public endpoint. Configure each endpoint independently to meet different business requirements.
For details, see Configure the connection settings for a database proxy endpoint and Use a database proxy endpoint to connect to an ApsaraDB RDS for PostgreSQL instance.
Read/write splitting
Database proxy endpoints automatically route write requests to the primary instance and read requests to read-only instances. This distributes the read load and prevents the primary instance from being overwhelmed by read-heavy traffic.
For details, see What is read/write splitting?
Transaction splitting
Transaction splitting is automatically enabled when you enable a database proxy and cannot be disabled. It routes read requests that appear before the first write operation in a transaction to read-only instances, reducing load on the primary instance.
Limitations:
Explicit transactions started with
BEGINorSTART TRANSACTIONcannot be split.Global consistency is not guaranteed. Evaluate whether your workloads can tolerate this before enabling the database proxy.
Transaction splitting cannot be disabled after the proxy is enabled.
For details, see Transaction splitting.
Proxy types
ApsaraDB RDS for PostgreSQL offers two proxy types:
| Item | General-purpose | Dedicated |
|---|---|---|
| Billing | Free of charge | Pay-as-you-go. See Billing rules for database proxies. |
| CPU resources | Shared | Exclusively allocated |
| Max specifications | 16 cores (8 database proxies) | 32 cores (16 database proxies) |
| RDS edition | RDS High-availability Edition | RDS High-availability Edition |
| Architecture | High-availability redundant | High-availability redundant |
| Read/write splitting | Supported | Supported |
| Transaction splitting | Supported | Supported |
| Proxy endpoints | 1–7; 1 internal + 1 public per endpoint | 1–7; 1 internal + 1 public per endpoint |
Choose General-purpose if cost is your primary concern and your workload can tolerate shared CPU resources.
Choose Dedicated if you need stable, predictable performance and your workload is sensitive to resource contention.
Proxy specifications follow this formula: Specification = Unit specification × Number of database proxies. The unit specification is fixed at 2 CPU cores. For example, 3 database proxies give you 6 CPU cores (2 × 3 = 6).
Limitations and billing
For the full list of usage constraints, see Usage notes of database proxies.
For pricing details, see Billing rules for database proxies.