Trading a Little Staleness for Lower Latency: Follower Reads in YugabyteDB

The problem: your reads travel to the leader

In a multi-region YugabyteDB cluster, every read that must be served by the tablet leader pays a network round trip to wherever the leader lives. If your users are spread across regions, that round trip shows up directly in read latency. Follower reads are the feature designed to address this: a SELECT can be answered by a follower replica in the client's region instead of the leader, at the cost of possibly returning slightly stale data.

What follower reads actually trade

A YugabyteDB tablet has one leader and two or more followers, replicated via Raft. The leader holds the newest committed data; followers may lag behind. When follower reads are enabled, the database picks a follower replica to serve the read, which means the data you read is as current as the follower has replicated. The key point: followers are not guaranteed to be only a few milliseconds behind. The guarantee is the configured staleness bound, controlled by yb_follower_read_max_staleness_ms, which defaults to 30000 ms (30 seconds) in current releases. If your application can tolerate that bound, follower reads can eliminate cross-region read latency for reads that don't need read-after-write consistency.

Enabling and verifying follower reads

Follower reads are controlled through the YSQL session GUC yb_read_from_followers. Connect with ysqlsh (ordinary user privileges are sufficient) and enable it per session:

SET yb_read_from_followers = true;

To allow a specific staleness window, set the bound explicitly:

SET yb_follower_read_max_staleness_ms = 100;

To confirm follower reads are active, run a simple read and check the latency, or use a read-only benchmark such as pgbench -S with follower reads on versus off. If your version exposes a follower-reads metric on the tserver metrics endpoint or Admin UI, you can also verify that requests are being routed to followers. The exact metric names and log strings vary by release, so check the docs for your version before relying on a specific counter.

When to avoid follower reads

Follower reads are a poor fit for reads that must observe your own writes. If the application requires strict read-after-write consistency, keep reads on the leader or implement application-level validation (for example, retry with a leader read if a version check fails). Also consider follower load: shifting read traffic to followers can increase replication lag if the followers are already resource-constrained. Monitor follower CPU, memory, and disk I/O, and consider adding more follower nodes or rebalancing tablets if lag grows.

A practical path forward

Start with a session-level toggle, verify the plan shows a follower read, and measure the latency reduction with a simple benchmark. If the trade-offs fit your workload, propagate the setting to your connection pool or application configuration for a persistent benefit.