Offload YugabyteDB Read Traffic with Follower Reads

The problem: one leader carries every read

In a YugabyteDB cluster, every table is split into tablets, and each tablet has a Raft leader. By default, both writes and reads go to that leader. If your application runs dashboards, reports, or other read-heavy queries against the same tablets that serve your write traffic, the leader nodes can become CPU hotspots while followers sit idle. Queries from clients in another availability zone also pay cross-zone latency to reach the leader.

The useful takeaway: YugabyteDB follower reads let SELECT queries run on follower replicas instead of the Raft leader. This can reduce leader load and improve read latency for geographically distributed clients, at the cost of possibly reading data that trails the latest write by a short replication lag.

What follower reads change (and what they don’t)

A follower read is served at a safe read point tracked by hybrid logical clocks, which means the result is consistent with some earlier point in time rather than the leader’s current state. The coordinator prefers a local follower when tablet placement and policy allow it, typically with a replication factor of three or more so followers exist.

Follower reads do not relieve leader bottlenecks for insert, update, or delete traffic. Writes still go to the leader. They also do not guarantee read-your-writes consistency: a row inserted through the leader may not immediately appear on a follower.

Worked example: enable follower reads for one session

Run these commands in ysqlsh connected to any cluster node. You need SELECT privileges on the target table; no special privileges are required to change this session parameter.

-- Check the current setting
SHOW yb_follower_reads;

-- Enable follower reads for this session only
SET yb_follower_reads = on;

-- Run a read-only query
EXPLAIN (ANALYZE, BUFFERS) SELECT * FROM  WHERE ;

Replace <table_name> and <condition> with your table and filter. After enabling, check that SHOW yb_follower_reads returns on. In the query plan, look for a follower scan rather than a leader-only path. Exact plan wording varies by release, so compare the plan before and after enabling instead of memorizing a keyword.

To test staleness under your topology, insert a row through the leader, then immediately issue the same SELECT from a session connected to a different zone with follower reads enabled. Record whether the new row appears. If it does not, your replication lag exceeds the gap between the write and the read.

The trade-off: staleness and failover

Follower reads suit eventually consistent workloads such as internal dashboards, read replicas for reporting, and background analytics. Avoid them for features that require read-your-writes consistency, such as a user viewing a profile just after updating it.

If no eligible follower is reachable because of zone failure or placement constraints, queries can fall back to the leader or return an error. Validate failover behavior before enabling this broadly. Turning follower reads on globally can also mask write-path latency problems, so enable it selectively per workload after load testing.

Verify the result and roll back

Measure leader CPU and average query latency before and after enabling follower reads under a read-heavy benchmark, and check tablet leader distribution in the admin console. If the feature causes stale reads or errors, disable it for the session:

SET yb_follower_reads = off;

Because this is a session-level setting, the rollback is immediate and affects only the current connection. If you changed it in server configuration instead, a restart is required to revert.

Follower reads are a good fit when read traffic overwhelms the leader and your application can tolerate slightly delayed data. Start with one read-heavy session or transaction, verify the plan and staleness in your own topology, then expand only where the numbers support it.