Read/write splitting is a database proxy feature that automatically routes write requests to the primary RDS instance and read requests to read-only RDS instances. Connect to a single database proxy endpoint—the proxy handles routing transparently, so your application code stays unchanged.
The diagram above shows how a single database proxy endpoint accepts all incoming requests and routes them: write operations go to the primary RDS instance, while read operations are distributed across read-only RDS instances.
For background on database proxies, see What are database proxies?
When to use read/write splitting
Read/write splitting is suited for workloads that are read-heavy but write-light. If your primary RDS instance is overloaded by read requests, read/write splitting lets you scale read capacity by adding read-only RDS instances without touching your application configuration.
Benefits
Simplified connection management
Without read/write splitting, you must add the endpoints of both the primary RDS instance and each read-only RDS instance to your application. Adding a new read-only instance requires an application config change.
With read/write splitting, your application connects to one database proxy endpoint. The proxy routes requests automatically. Adding or removing read-only RDS instances requires no changes to your application.
Native integration for lower latency
Read/write splitting is built directly into the ApsaraDB RDS ecosystem. Requests reach the database without passing through additional parsing and forwarding layers, reducing response latency and lowering maintenance overhead.
Automatic health checks
Read/write splitting continuously monitors the health of the primary RDS instance and all read-only RDS instances. If a read-only instance fails or its data replication latency exceeds the configured threshold, the proxy stops forwarding reads to that instance and redirects them to healthy instances. When the instance recovers, the proxy resumes sending reads to it automatically.
Configurable routing weights and thresholds
Assign read weights to the primary RDS instance and each read-only RDS instance to control how reads are distributed. Set a replication latency threshold to define when a read-only instance is considered too far behind to serve read requests.
How requests are routed
Read-only RDS instances serve reads only—they do not accept writes:
| Operation type | Primary RDS instance | Read-only RDS instances |
|---|---|---|
| Writes (INSERT, UPDATE, DELETE, SELECT FOR UPDATE) | Yes | No |
| Reads (SELECT) | Yes | Yes |
The table below shows the full routing behavior for all request types.
| Destination | Request types |
|---|---|
| Primary RDS instance only | INSERT, UPDATE, DELETE, and SELECT FOR UPDATE statements; DDL operations (create or drop databases and tables, change schemas or permissions); requests in transactions; user-defined function calls; stored procedure calls; multi-statements; requests involving temporary tables; read and write requests for system tables; write operations in prepared statements |
| Primary RDS instance or read-only RDS instances | SELECT statements not in transactions; requests before the first write in a transaction when transaction splitting is enabled; read operations in prepared statements; system functions that are safe to run on read-only instances (for example, pg_sleep) |
| Primary RDS instance and read-only RDS instances | System variable reconfiguration requests; parsing operations in prepared statements; BEGIN, START, END, ROLLBACK, and COMMIT; CANCEL |