In a multi-region YugabyteDB cluster, tablet leaders matter.
Every strongly consistent read and every write is served by the tablet leader. A tablet is a partition of a table, and the leader is the replica responsible for coordinating reads and writes for that tablet.
By default, tablet leaders can be spread across regions. That is great for distributing load, but it can surprise you when the application is mostly running in one region.
If your application is in Region A, but the tablet leader for the data it needs is in Region B, the request has to cross the network to reach the leader. In a US East-to-West deployment, that round-trip can easily add tens of milliseconds. A query that feels instant in a single-region deployment can suddenly look slow, even when the database is not CPU-bound, not disk-bound, and not missing cache.
The fix is to configure leader preference so tablet leaders live close to the application.
YugabyteDB supports this through the yb-admin set_preferred_zones command or through the Preferred setting in YugabyteDB Anywhere. The setting tells YugabyteDB which region or availability zone should be preferred for tablet leaders. Tablet leaders are placed on healthy nodes in the preferred zones according to priority
The Problem
In a distributed SQL database, not all latency comes from query planning, disk access, or cache misses.
Sometimes the latency is simply geography.
For example, imagine this topology:
Example Topology
Application runs in Region A, but some tablet leaders are in Region B or Region C. Even a simple point lookup may need to cross regions before the result can be returned.
For a point-select that uses a secondary index, the query may need to:
- 1. Read from the index tablet.
- 2. Use the result to fetch the base table row.
If both operations have to reach remote tablet leaders, the query may pay for multiple cross-region round trips.
That means a query with excellent cache behavior can still be slow.
What This Looks Like
In one real-world troubleshooting case, a simple point-select in a 3-region cluster showed latency around 86 ms.
The storage layer accounted for most of the time, with roughly:
The interesting part?
RocksDB block cache hit rate was effectively 100%.
So this was not a disk problem. It was not a cache problem. It was network-bound latency caused by cross-region leader access.
In this case, the application was simply routing traffic to the wrong region, adding unnecessary latency before the database even had a chance to do useful work.
Why Preferred Zones Help
Preferred zones tell YugabyteDB where tablet leaders should live.
If the application primarily runs in one region, placing leaders in that same region helps reduce cross-region hops for strongly consistent reads and writes.
YugabyteDB documentation describes this pattern as designating a preferred region when application reads and writes originate primarily from one region. In that model, the preferred region handles the read and write workload, while non-preferred regions continue to host follower replicas for resilience.
Example yb-admin command:
./bin/yb-admin \
-master_addresses <master-ip-1>:7100,<master-ip-2>:7100,<master-ip-3>:7100 \
set_preferred_zones \
aws.us-east-1.us-east-1a:1 \
aws.us-east-1.us-east-1b:1 \
aws.us-east-1.us-east-1c:1
The exact cloud, region, and zone names should match your cluster placement configuration.
You can also configure this in YugabyteDB Anywhere by editing the universe and marking the desired availability zone as Preferred.
Key Insight
Preferred zones do not make the network faster. They reduce how often your application has to cross the network to reach tablet leaders.
When This Is the Right Pattern
Preferred zones are a good fit when most application reads and writes originate from one region.
For example:
What About Follower Reads?
Preferred zones help strongly consistent reads and writes by placing leaders closer to the application.
Follower reads solve a different problem.
For read-heavy workloads where slightly stale results are acceptable, YugabyteDB can read from the nearest replica instead of always going to the leader. This is controlled by:
SET yb_read_from_followers = true;
The default is false.
Follower reads use yb_follower_read_staleness_ms to determine how stale the read can be. The default is 30000 ms, or 30 seconds. YugabyteDB documentation notes that the staleness value should not be set lower than 2x raft_heartbeat_interval_ms, which defaults to 500 ms, making the practical minimum 1000 ms.
Example:
SET yb_read_from_followers = true;
SET yb_follower_read_staleness_ms = 30000;
SET session characteristics as transaction read only;
YugabyteDB’s global application documentation shows follower reads being used to reduce read latency by allowing reads from the closest follower or leader.
Important Caveat
Follower reads are always stale reads. Even if the nearest replica is also the leader, the read is performed at an older timestamp based on yb_follower_read_staleness_ms. Use this only when the application can safely tolerate stale data.
How to Validate the Issue
When troubleshooting unexpectedly high latency in a multi-region cluster, check the following:
Best Practice
For multi-region deployments, decide where the workload should be served from before going live.
Do not assume the database will automatically place every leader near the application. In a multi-region cluster, leader placement is a design decision.
Use preferred zones when the application is primarily active in one region.
Use follower reads when the workload is read-heavy and can tolerate stale data.
Use geo-partitioning or more advanced global application patterns when different regions need low-latency access to different subsets of data.
Final Takeaway
In YugabyteDB, latency follows the leader. If your application runs in one region, make sure your tablet leaders are there too. Preferred zones are one of the simplest and most effective ways to avoid unnecessary cross-region round trips in multi-region deployments.
Have Fun!
