I originally wrote most of this back in December, which is why the “traditional” image I include at the bottom of every tip matches that timeframe. 🙂
YugabyteDB 2025.2.1.0 introduces a new feature called Write Pipelining (also referred to as Async Writes) which dramatically reduces write latency… especially in multi-AZ and multi-region deployments.
Traditionally, YugabyteDB acknowledges a write only after it is quorum-replicated via Raft, ensuring strong consistency. This model is extremely safe but also means every write incurs 1–2 network round trips (RTT), and in multi-region setups those RTTs can easily be 50–150 ms each.
Async Writes redesign this flow so clients can keep moving without waiting on Raft for every statement.
🔍 The Problem: RTT Adds Up… Very Quickly
In YSQL, a multi-statement transaction might look like:
BEGIN;
INSERT …
INSERT …
SELECT …
INSERT …
COMMIT;
Without Write Pipelining, each INSERT waits for a Raft quorum commit before PostgreSQL continues. A four-statement batch may cost 4× RTT, which in multi-region deployments is painful.
This behavior comes directly from the existing DocDB rules… every write must be durable on a majority of replicas before YSQL receives an ACK.
🚀 Enter Async Writes (Write Pipelining)
Async Writes flip the model!
🔸 What changes?
When a write arrives at the tablet leader, YugabyteDB will:
Grab locks
Create the in-memory intent
Pick the hybrid timestamp (HT)
ACK immediately to PostgreSQL, returning a unique
async_query_id
The Raft quorum commit then proceeds asynchronously, in the background.
🔸 What does PostgreSQL do with this?
The YSQL layer tracks all in-flight async writes. It can continue issuing more writes or reads in parallel (even to the same key/tablet) without waiting.
Only when the user issues a COMMIT, PostgreSQL will:
● Wait for all
async_query_ids to finish (i.e., replication to complete)● Then perform the final transaction commit at the Status Tablet
⭐ The Result
Because all writes replicate concurrently, the entire transaction now sees a fixed cost of ~2 RTT instead of N × RTT
📉 Why This Matters (Even More Across Regions)
Because YugabyteDB tablets are often distributed across multiple zones or even multiple regions:
● Single-region RTT: ~2–3 ms
● Multi-region RTT: ~50–150 ms
● Multi-statement transactions previously multiplied these numbers
With Write Pipelining:
● RTT is paid once at COMMIT
● The rest of the transaction continues without waiting
It’s easy to see why this is a huge boost for globally distributed apps.
🧠 Additional Benefits
- ✔️ Works with both YSQL and YCQL
- ○ Async Writes sit below the query layer… no planner changes required.
- ✔️ No behavioral changes for complex SQL plans
- ○ Because the logic lives inside
pg_client_session, PostgreSQL is unaware of the mechanism.
- ○ Because the logic lives inside
- ✔️ Minimal sensitivity to graceful failovers
- ○ YB ensures that in-flight async writes are completed before leader transitions.
- ✔️ Significant performance improvements
- ○ 10–30% lower latency across TPCC
- ○ Multi-index writes become dramatically faster
- ○ With leader affinity, YSQL latency becomes 10–15% lower than Amazon Aurora
⚠️ What About Safety?
Because intent writes happen before WAL replication, an ungraceful leader crash may result in a “stale” intent. However:
● The async write will fail
● PostgreSQL aborts the entire transaction
● Consistency remains guaranteed
This aligns with YugabyteDB’s CP guarantees: correctness over availability. (See: Partition Tolerance – CAP)
🛠 Example: Before vs. After
The results below compare sysbench performance on a YugabyteDB cluster with Write Pipelining disabled versus enabled, using a range of thread counts.
For each transaction generated by sysbech, the number of SQL operations included:
- ● 10 SELECTs
- ● 50 INSERTs (One 50 row INSERT)
- ● 20 UPDATEs
- ● 10 index-column updates
- ● 10 non-index-column updates
- ● 1 DELETE
Without Async Writes: The throughput was 10-74 events / second and the average latency was 300–500 ms in the multi-region setup
With Async Writes: The throughput was 59-400 events / second and the average latency was just 66–82 ms in the multi-region setup!
🎯 When Should You Use It?
✔️ Multi-AZ or multi-region deployments
✔️ High-latency environments
✔️ Workloads with many sequential writes per transaction
✔️ App architectures where leaders are pinned close to the application tier
📝 Summary
Write Pipelining / Async Writes is one of the most important latency-reducing features introduced to YugabyteDB in years:
● Writes are acknowledged immediately
● Raft replication continues asynchronously
● PostgreSQL can continue issuing statements without stalling
● COMMIT becomes the single synchronization point
● Transactions complete in a predictable ~2 RTT
● Large performance gains across real workloads (TPCC, Sysbench)
This is a major win for globally distributed SQL applications.
Have Fun!
