YugabyteDB Follower Reads: Cut Leader Load Without Breaking Consistency

Read Traffic Should Not Always Wait for the Raft Leader

If your YugabyteDB cluster serves a read-heavy workload across availability zones, every SELECT may still route to the Raft tablet leader. Writes must be committed by the leader, but sending all reads there adds cross-zone latency and concentrates CPU on one replica per tablet. YugabyteDB YSQL follower reads let eligible SELECT statements run on a follower replica instead.

The practical takeaway: turn follower reads on per session for dashboards, feeds, and reports that can tolerate replication lag. Keep inventory checks, financial reads, and any read-your-writes flow on the leader. Verify the offload with tablet-server metrics before trusting it in production.

Leader Reads vs. Follower Reads

YugabyteDB replicates each tablet using the Raft consensus algorithm. One replica is the tablet leader; the others are followers. By default, YSQL sends reads and writes to the leader. A follower read is a YugabyteDB-specific YSQL behavior that permits a specific SELECT to execute on a follower, bypassing the leader for that query. Mutations such as INSERT, UPDATE, and DELETE always go to the leader.

This is not standard PostgreSQL behavior. The exact session variable name and default can differ between YugabyteDB releases, so confirm the syntax in your installed version's YSQL documentation before applying the example below.

Worked Example: Opt In for One Session

Run these statements in a YSQL client session (ysqlsh or your application connection). Ordinary login privileges are sufficient; no superuser or OS-level access is required.

-- Replace the setting name with the one documented for your YugabyteDB version
SET SESSION yb_follower_reads = on;

-- This SELECT may be served by a Raft follower tablet
SELECT * FROM user_profiles WHERE user_id = 'user-123';

-- Return to leader reads for the remainder of the session
SET SESSION yb_follower_reads = off;

Placeholder 'user-123' represents a real primary key in your schema. If your application uses connection pooling, set or reset this mode after checking out a connection so a follower-read session is not reused for a transaction that requires freshly written data.

Consistency Trade-Off

Data on a follower can lag the leader by the Raft replication delay. Follower reads do not provide read-your-writes consistency: a row inserted moments earlier may be missing or stale when read from a follower.

Avoid follower reads for:

• Inventory reservation immediately after an order
• Account balance reads after a transfer
• Any operation requiring linearizable consistency right after a mutation

Suitable targets include public profile views, recommendation feeds, aggregated analytics, and dashboard metrics where sub-second staleness is acceptable.

Verify That Traffic Is Actually Offloaded

Check tablet-server metrics on the node serving as Raft leader. Compare leader CPU utilization and leader read request rate before and after enabling follower reads. A useful signal is rising follower-read request volume alongside falling leader read traffic.

For a functional check, write a test row, wait longer than the expected replication lag, then read it through a follower and compare the result to a leader read. If the values match under normal lag, the follower path is serving data. If they diverge beyond expected replication delay, investigate tablet health or network latency before enabling the setting more broadly.

Actionable Closing

Do not enable follower reads globally by default. Use explicit session opt-in so consistency assumptions remain visible in application code. Review your YugabyteDB release notes and YSQL documentation for the exact follower-read syntax and defaults, then run a write-then-read latency test from a client in another region to confirm the trade-off fits your workload.