YugabyteDB Follower Reads: Lower Geo-Read Latency

Problem: cross-region read latency

In YugabyteDB each tablet (a shard of a table) is replicated via Raft. Normally, reads go to the tablet's leader because only the leader guarantees you're seeing the latest committed data.

How follower reads work

Follower reads relax this. Each tablet tracks a safe time — a hybrid-logical-clock timestamp up to which the replica's state is known to be consistent. When you request a follower read with a staleness bound, the database asks: Does this follower's safe time cover a point no more than X milliseconds behind now? If yes, the follower serves the read. If no — say the follower is lagging due to a network blip — the request transparently falls back to the leader.

Enabling follower reads

Follower reads are controlled by session variables, so there's no DDL and no cluster restart. On tserver versions 2.14 and later the feature is enabled by default (--enable_follower_reads=true); on earlier versions it was experimental and needed the flag set explicitly. Run these in your application's SQL session or connection pool initializer:

Role-level default

Worked example

Take a three-region cluster - us-east-1, eu-west-1, ap-south-1 - with a users table. Tablet leaders tend to concentrate near the placement's preferred region, so a SELECT from the EU app normally hops to us-east.

With the settings above applied in the EU app's sessions, a query like:

EXPLAIN ANALYZE SELECT * FROM users WHERE id = 42;

now executes against the eu-west follower. You can confirm the path in the plan output — look for the read request type indicating a follower read rather than a leader read. In latency terms, you're replacing a cross-region round trip with a local one; the actual numbers depend on your network, so measure with the settings on and off rather than trusting any single benchmark.

To see where leaders and followers actually sit, query the system views:

This requires no special permissions beyond catalog access and is a good sanity check that replicas exist in the regions you expect — follower reads can't help if there's no follower near your app.

Where it can go wrong

• No read-your-writes. The staleness bound is a maximum, not a guarantee of freshness. Don't use follower reads for account balances, inventory decrements, or anything where a stale answer causes a wrong decision.
• Transactions ignore it. Inside BEGIN ... COMMIT, reads go to the leader for snapshot isolation. SELECT ... FOR UPDATE and other locking clauses also bypass follower reads.
• Silent fallback under stress. During leader elections, partitions, or heavy write load, follower safe time can lag past your bound. Reads then fall back to the leader — correct, but with the latency spike you were trying to avoid. If replication lag chronically exceeds your bound, follower reads are effectively off for those tablets.
• Version differences. Pre-2.14 behavior was experimental; verify against the docs for your exact version before rolling out.

Verifying in production

Don't assume the session variable took effect — connection poolers can reset session state. Check with SHOW yb_read_from_followers; from an actual pooled connection. Then watch the tserver metrics: follower-read request counts tell you the feature is being used, and the fallback counter tells you how often safe time couldn't keep up. A rising fallback rate during peak write hours is your signal to either widen the staleness bound or accept leader reads for that window.

The actionable next step: pick one genuinely staleness-tolerant read path — a dashboard, a product catalog, a feed — enable follower reads for just that role, and compare p99 latency before and after. That single measurement will tell you more than any configuration guide.