Write Pipelining (Async Writes) – Faster Writes, Even Across Regions

⏳ Quick note on timing
This tip took a little longer than usual to publish because I wanted to wait until Write Pipelining / Async Writes was actually live and available.

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:

  1. Grab locks

  2. Create the in-memory intent

  3. Pick the hybrid timestamp (HT)

  4. 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.
  • βœ”οΈ 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!

πŸŽ„ Finally got the Christmas tree up! Only thing missing are some YugabyteDB ornaments… πŸ€” Where do I get those from? Let me reach out to Marketing! πŸ˜„