Cutting Read Latency in YugabyteDB with Follower Reads

Problem: reads hop across regions and add latency

In a geo-distributed YugabyteDB cluster, the leader replica for a specific tablet lives in one region. When a client in a different region issues a read request, that request must travel across the network to the leader, wait for the leader to apply any pending Raft entries, and then travel back to the client. This cross-region round-trip introduces significant latency, which can be a bottleneck for read-heavy workloads such as real-time dashboards, API endpoints, or content delivery systems where milliseconds matter.

Thesis: follower reads trade bounded staleness for local latency

YugabyteDB's follower reads feature leverages the underlying Raft consensus layer to allow any replica—not just the leader—to serve read requests. A follower can respond to a read once it has applied the latest committed entry, provided the data falls within a user-defined staleness bound. If the follower is too far behind the leader, the request is redirected to the leader to ensure correctness. By enabling this feature, applications can serve reads from the nearest replica, dramatically reducing latency for workloads that can tolerate slightly stale data.

Enabling and configuring follower reads

Follower reads are configured at the YSQL session level, meaning they can be toggled on a per-connection basis without requiring a cluster restart. To enable the feature, set the session variable yb_follower_reads to true. To control the consistency trade-off, use yb_read_from_follower_max_staleness_ms to define the maximum allowed lag in milliseconds.

-- Enable follower reads for the current session
SET yb_follower_reads = true;

-- Set the maximum allowed staleness to 500 milliseconds
SET yb_read_from_follower_max_staleness_ms = 500;

If yb_read_from_follower_max_staleness_ms is set to 0, there is no explicit time limit, but the follower must still be caught up with the leader's latest committed entry to serve the read locally.

Worked example: verifying follower read execution

1. Start a local three-node YugabyteDB cluster using yb-ctl or docker-compose. Create a sample table and populate it with data to ensure there are tablets to distribute across the nodes:

   CREATE TABLE accounts (id BIGINT PRIMARY KEY, balance NUMERIC);
   INSERT INTO accounts SELECT generate_series(1,10000), random()*1000;
   

2. Connect via psql and enable follower reads for your session:

   SET yb_follower_reads = true;
   SET yb_read_from_follower_max_staleness_ms = 200;
   

3. Run an EXPLAIN command on a select query to verify the execution plan:

   EXPLAIN SELECT * FROM accounts WHERE id = 42;
   

   In the output, look for a node labeled Read from follower. If the plan shows a standard read from the leader, it indicates that the local follower did not meet the staleness bound or the query was routed to the leader for other optimization reasons.

4. To quantify the benefit, run a select-only benchmark using pgbench:

   pgbench -c 4 -j 2 -T 30 -S -h localhost -p 5433 yugabyte
   

   Compare the average response times with yb_follower_reads set to true versus false to see the latency reduction.

Trade-offs and limitations

• Staleness Bound Sensitivity: If the max_staleness_ms is set too low (e.g., lower than the actual network replication lag), followers will frequently fail the staleness check. This causes the system to redirect reads back to the leader, negating the latency benefits.

• Consistency Model: Follower reads provide bounded-staleness consistency rather than strict serializability. This is unsuitable for read-after-write patterns where an application updates a record and must immediately read the updated value.

• Write-Heavy Workloads: In environments with extremely high write volume, replication lag may increase, making it harder for followers to stay within the staleness window.

Actionable closing

For read-dominant workloads in multi-region clusters, follower reads are a powerful tool to eliminate cross-region hops. Start by identifying queries that can tolerate a few hundred milliseconds of lag. Enable the feature at the session level, use EXPLAIN to verify that reads are hitting followers, and monitor your replication lag via the YugabyteDB admin UI to tune your staleness bound for the best balance of performance and freshness.