Does YugabyteDB guarantee read-your-writes consistency for cross-tablet queries in multi-region DocDB deployments?

Direct answer

Assumes a recent stable YugabyteDB 2.x cluster with DocDB, default YSQL READ COMMITTED, and follower reads permitted. No. Enabling follower reads does not by itself guarantee read-your-writes consistency for a cross-tablet read. A same-session read observes its own write only when the read hybrid time is at or after the write’s commit hybrid time and the serving follower replica has applied through that time within the configured follower-read staleness bound. Otherwise the cross-tablet read may wait for replication, fall back to the tablet leader, or return a snapshot that predates the write.

Confirmed behavior

• DocDB orders writes with hybrid logical timestamps, and a client session advances its read hybrid time after a write.
• Follower reads are served only from replicas whose safe read time covers the requested read time.
• Cross-tablet reads use one distributed read hybrid time across participating tablets, so a multi-tablet transaction commits at a single hybrid time and a subsequent READ COMMITTED statement snapshots at statement start rather than mixing independent tablet clocks.
• YSQL’s default READ COMMITTED does not by itself break read-your-writes; each statement takes a fresh snapshot at statement start, and earlier same-session writes are visible if the snapshot time is at or after their commit time.
• Tablet splitting is a metadata rebalance. An in-flight cross-tablet query resolves tablet locations from a snapshot at query start, so a split does not inherently create a follower-lag window beyond the HLT bound, though it can cause transient re-planning, tablet-lookup redirects, or brief unavailability of the split tablet.

Likely explanation and uncertainty

The practical risk in multi-region deployments is cross-region replication delay between the write leader and a local follower. If that lag exceeds the follower-read staleness bound, the local follower cannot serve the read fresh enough, so read-your-writes is violated unless the read waits or goes to the leader. This is a likely explanation, not a versioned guarantee; behavior can change between YugabyteDB releases.

Verification steps

1. Confirm the YugabyteDB version and whether follower reads are enabled for the cluster and session.
2. Check the configured follower-read staleness bound or max follower read lag.
3. Run a same-session write through the YSQL leader, then immediately run a cross-tablet SELECT with EXPLAIN to confirm whether the read is served by a follower, and verify the row appears.
4. Repeat with the follower artificially lagged or with reads forced to the leader to observe the fallback path.
5. Inspect tablet-server and master logs for safe read time, read hybrid time, and follower-read wait or fallback events during the test.

BEGIN;
INSERT INTO orders (id, region) VALUES (1, 'us-east');
EXPLAIN SELECT o.id, i.item FROM orders o JOIN items i ON o.id = i.order_id WHERE o.id = 1;
SELECT * FROM orders WHERE id = 1;
COMMIT;

Missing diagnostic detail

What is the configured follower-read staleness bound (max follower read lag), and are reads pinned to leaders for the session? This detail changes the recommendation because it determines whether a non-leader replica can satisfy read-your-writes after a cross-region write.