YugabyteDB Follower Reads – Reduce Read Latency

Learn how YugabyteDB follower reads let you serve SELECT queries from replica tablets to cut read latency, with a concrete example, setup steps, and consistency trade‑offs.

Problem: Read latency hurts user experience

When an application serves users from multiple regions, read requests that always go to the leader tablet can add hundreds of milliseconds of network latency. Even in a single‑region deployment, leader‑only reads can become a bottleneck under heavy traffic because the leader handles both writes and all read traffic.

Thesis: Follower reads give low‑latency reads with a predictable consistency trade‑off

YugabyteDB’s follower‑read feature lets a session direct SELECT queries to replica tablets (followers) instead of the leader. The data is eventually consistent, typically lagging the leader by less than a second in same‑region clusters, but the read path is shorter because the follower is often geographically closer to the client.

Enabling follower reads for a session

The feature is controlled by the YSQL session variable yb_follower_read. Setting it to on tells the planner to route qualifying SELECT statements to follower tablets. No schema changes or restarts are required.

-- Enable follower reads for the current session
SET yb_follower_read = ON;
-- Verify the setting
SHOW yb_follower_read;
-- Expected output: on

Once enabled, any subsequent SELECT in that session will be considered for follower routing. The planner still chooses the leader for queries that require strong consistency (e.g., those involving recent writes within the same transaction).

Worked example: checking that a read hit a follower

Assume a table public.users with a column updated_at that is refreshed by a background job every few seconds.

Update a row to create a known recent timestamp.

UPDATE public.users SET updated_at = now() WHERE id = 42;

Enable follower reads and run a SELECT that reads the same row.

SET yb_follower_read = ON;
SELECT id, updated_at FROM public.users WHERE id = 42;

Compare the returned updated_at with the current time. A small difference (typically a few hundred milliseconds) indicates the data came from a follower that is slightly behind the leader.
```
SELECT now() AS server_time,
       (SELECT updated_at FROM public.users WHERE id = 42) AS row_time,
       now() - (SELECT updated_at FROM public.users WHERE id = 42) AS lag;
```
Optionally, verify tablet involvement via the Admin UI: navigate to Tablet → Server → Role and confirm that the tablet serving the query is marked FOLLOWER.

If the lag column shows a value close to zero, the query likely hit the leader (perhaps because the planner decided strong consistency was needed). Repeating the test after a brief wait should show a non‑zero lag when follower reads are active.

Trade‑offs and limitations

Consistency model: Follower reads are eventually consistent. They are unsuitable for scenarios that require read‑your‑writes or serializable guarantees unless you explicitly fall back to leader reads for those transactions.
Resource impact: Heavy read traffic shifted to followers can increase their CPU and I/O usage. Monitor tablet‑level metrics (e.g., yb_tserver_tablet_cpu_usage) to ensure no follower becomes a hotspot.
Geographic benefit: The latency reduction is most noticeable when followers are placed in regions close to the client. In a single‑region cluster, the gain is modest but still useful for off‑loading the leader.

Actionable closing

To start using follower reads today:

Identify read‑heavy, latency‑sensitive queries that can tolerate slight staleness.
Wrap those queries in a session where SET yb_follower_read = ON; is executed.
Verify the setting with SHOW yb_follower_read; and check for replication lag as shown in the example.
Set up alerts on follower tablet CPU/I/O to catch overload early.
For transactions that need strict consistency, either disable follower reads (SET yb_follower_read = OFF;) or route them explicitly to the leader.

By toggling the feature per session, you gain the ability to balance latency and consistency without schema changes or downtime, making follower reads a practical tool for geo‑distributed YugabyteDB deployments.

Using Follower Reads in YugabyteDB to Cut Read Latency