In a multi-region YugabyteDB deployment, an application can be connected to a local YB-TServer and still occasionally experience cross-region latency during query parsing, planning, connection startup, or after schema changes.
The reason is that YSQL depends heavily on PostgreSQL system catalogs such as pg_class, pg_attribute, pg_proc, pg_operator, and pg_statistic. YugabyteDB caches this metadata aggressively, but a cache miss can require communication with the YB-Master leader that owns the SysCatalog tablet. Once a backend’s catalog cache is warm, many of those lookups are served directly from backend memory.
For geographically distributed applications, this leads to two natural questions:
- ● Can catalog reads be served from a region-local replica?
- ● Can the SysCatalog leader be placed closer to the application?
As of September 2026, there are useful ways to reduce the impact, although they work a little differently than follower reads for ordinary application data.
set_preferred_zones affects leader affinity, and by default the SysCatalog leader will step down to a YB-Master already running in a preferred zone.
The YugabyteDB documentation explicitly notes that set_preferred_zones influences the SysCatalog leader as well as normal tablet leader placement. It does not move the YB-Master processes themselves.
Understanding the Catalog Read Path
At a high level, the steady-state goal is:
The expensive path is:
This is why a catalog-cache miss that is nearly invisible in a single-region deployment can become noticeable when the YSQL backend and YB-Master leader are separated by significant network latency. YugabyteDB’s tuning guide explicitly describes the tradeoff between latency fetching catalog entries from a remote YB-Master and the memory cost of caching more metadata locally.
Tips for Reducing Catalog RPC Latency
1. First, Prove That Catalog Reads Are the Problem
Don’t assume every cross-region latency spike is coming from SysCatalog.
For a query showing high first-execution latency, open a new connection and run:
EXPLAIN (ANALYZE, DIST)
SELECT ...;
Then execute the same query again on the same connection.
The YugabyteDB catalog tuning guide specifically recommends comparing the first and subsequent execution. If catalog caching is involved, the first execution can show a larger number of Catalog Reads, while subsequent executions typically show fewer.
This is a particularly useful distinction:
If both executions are equally slow, the problem may be elsewhere.
2. Watch Catalog Cache Misses
YugabyteDB exposes Catalog Cache Misses metrics, including breakdowns by pg_catalog table. A miss represents metadata that was not available in the local YSQL backend cache and had to be fetched from YB-Master.
One of the underlying metrics is:
handler_latency_yb_ysqlserver_SQLProcessor_CatalogCacheTableMisses_count
Look for two things occurring together:
That correlation is much stronger evidence than simply observing elevated query latency.
3. Reuse Connections
One of the highest-value optimizations is also one of the simplest:
- Don’t continuously throw away warm PostgreSQL backends.
Each backend maintains its own PostgreSQL catalog cache. A new backend starts cold and must warm the metadata needed by its workload.
Connection pooling therefore turns this:
into:
The official tuning guide recommends connection pooling specifically for catalog-cache-related latency and YB-Master load. Options include YSQL Connection Manager, application/client-side pools, PgBouncer, and similar pooling layers.
4. Look for Connection Churn
Even if an application claims to use pooling, verify the actual behavior.
Common causes of excessive backend creation include:
- ● Pools configured with very short connection lifetimes
- ● Autoscaling application tiers
- ● Serverless workloads
- ● Health checks that open fresh database connections
- ● Large numbers of independent microservices
- ● Pools that frequently shrink back to zero
- ● Connection storms following application restarts
- ● Load balancers or proxies closing otherwise reusable connections
The key metric is not simply how many connections exist. It is how frequently new PostgreSQL backends are being created.
5. Preload Frequently Used Catalog Tables
For workloads that consistently need certain system catalogs, YugabyteDB can preload additional catalog tables.
A broad option is:
--ysql_catalog_preload_additional_tables=true
- ●
pg_am - ●
pg_amproc - ●
pg_cast - ●
pg_inherits - ●
pg_policy - ●
pg_proc - ●
pg_tablespace - ●
pg_trigger
The purpose is to trade some additional memory for lower first-query catalog latency.
6. Better Yet: Preload Only What Your Workload Needs
Rather than enabling a broad list blindly, identify the catalogs actually involved in your workload.
Use:
SET yb_debug_log_catcache_events = 1;
SET backtrace_functions = 'SearchCatCacheMiss';
SET client_min_messages = LOG;
EXPLAIN (ANALYZE, DIST)
SELECT ...;
The resulting output identifies catalog tables involved in misses. YugabyteDB’s documentation recommends using these observations to populate:
--ysql_catalog_preload_additional_table_list=<catalog tables>
For example:
--ysql_catalog_preload_additional_table_list=pg_operator,pg_amop,pg_cast,pg_aggregate
7. Don’t Preload Everything
Catalog preloading is a classic memory-versus-latency tradeoff.
Every backend maintains its own catalog cache, so preloading more metadata increases memory consumption across all PostgreSQL backends. It can also increase backend initialization work.
8. Don’t Accidentally Optimize for Memory at the Expense of Latency
The YugabyteDB documentation also mentions:
--ysql_minimal_catalog_caches_preload=true
This reduces the amount of catalog metadata preloaded and therefore lowers memory consumption, but the tradeoff is potentially higher initial query latency.
For a workload specifically suffering from cross-region catalog latency, understand that tradeoff before enabling it.
9. Keep YB-TServer Read Request Caching Enabled
The flag:
ysql_enable_read_request_caching
is enabled by default. It enables the YB-TServer read-request caching infrastructure used by several catalog optimizations.
Unless you have a specific reason to change it, this is generally not something you want disabled while trying to reduce repeated catalog traffic.
10. Cache Authentication Catalog Reads During Connection Churn
YugabyteDB 2026.1 includes additional optimizations for connection authentication.
The flag:
ysql_enable_read_request_cache_for_connection_auth=true
allows connection-authentication catalog prefetches such as pg_authid and pg_database to be served from the YB-TServer response cache instead of generating a fresh YB-Master read for every new connection. It applies to regular YSQL backends as well as Connection Manager authentication backends.
This is particularly useful if your catalog load correlates strongly with new connection creation.
One caveat: the authentication response cache is not used when YSQL login profiles are enabled.
11. Place the SysCatalog Leader Near the Primary Application Region
If most application traffic originates in one region, leader placement can also help.
For example:
yb-admin \
--master_addresses master1:7100,master2:7100,master3:7100 \
set_preferred_zones \
aws.us-east-1.*:1 \
aws.us-central-1.*:2 \
aws.us-west-2.*:3
set_preferred_zones controls cluster leader affinity. Importantly, YugabyteDB documents that the SysCatalog leader also steps down to a YB-Master already running in a preferred zone by default.
So if most of your applications are in us-east-1, placing the master leader there can reduce the network portion of an unavoidable catalog cache miss.
12. Remember: set_preferred_zones Is Not a SysCatalog-Only Setting
This is an important caveat.
set_preferred_zones changes leader affinity for the cluster. It is not a dedicated switch for moving only the SysCatalog leader.
It affects normal tablet leaders too, while the SysCatalog leader follows the same preferred-zone policy by default.
That may be exactly what you want in a primary-region architecture. It may be undesirable in a truly symmetric active-active application architecture.
Evaluate the impact on the complete workload before changing it solely to improve catalog access.
13. A YB-Master Must Already Exist in the Preferred Region
set_preferred_zones does not relocate YB-Master processes.
The documentation is explicit that the SysCatalog leader steps down onto a master already running in the preferred zone.
So this topology works:
This topology cannot magically move the leader into a region that contains no master:
14. Prefer a Region, Not Necessarily One Exact AZ
If the goal is regional locality rather than pinning to one availability zone, use a region wildcard:
aws.us-east-1.*:1
Alternatively, assign multiple AZs within the same region the same preference rank:
aws.us-east-1a:1
aws.us-east-1b:1
aws.us-central-1a:2
YugabyteDB allows multiple zones to share the same preference rank.
This gives the system more flexibility to move leadership within the preferred region.
15. Verify Where the Master Leader Actually Lives
Don’t assume the affinity change worked.
Use:
yb-admin \
--master_addresses master1:7100,master2:7100,master3:7100 \
list_all_masters
Example:
Master UUID RPC Host/Port State Role
... master1:7100 ALIVE LEADER
... master2:7100 ALIVE FOLLOWER
... master3:7100 ALIVE FOLLOWER
list_all_masters explicitly reports which YB-Master is currently LEADER.
Map that host back to its region and verify that it matches your intended topology.
16. Route Applications Toward the Same Preferred Region
If a preferred region has been selected, try to keep the application connection path aligned with it.
YugabyteDB recommends using topology keys with topology-aware/smart drivers to target preferred zones.
Fewer WAN hops are usually better.
17. Don’t Confuse SysCatalog With Transaction Status Tablets
These are separate concerns.
The flag:
transaction_tables_use_preferred_zones
controls whether transaction status tablet leaders respect the preferred-zone configuration. Its documented default is false.
It does not control the SysCatalog leader.
Think of these independently:
A tuning recommendation for one should not automatically be applied to the other.
18. Follower Reads Can Still Help Your Application – Just Not This Particular Problem
YSQL follower reads allow read-only application queries to read from the closest replica when some staleness is acceptable:
SET SESSION CHARACTERISTICS AS TRANSACTION READ ONLY;
SET yb_read_from_followers = true;
The default follower-read staleness is 30 seconds.
That can dramatically reduce cross-region latency for application data.
But it should not be confused with catalog caching. Current catalog documentation still describes cache misses and refreshes as obtaining metadata from YB-Master; follower reads are not documented as a mechanism for making YSQL catalog misses region-local.
19. Expect Some Catalog Activity After DDL
Schema changes invalidate catalog information.
Modern YugabyteDB releases use incremental invalidation messages by default, so individual affected cache entries can be invalidated rather than forcing a complete catalog refresh for every schema change. Disabling ysql_yb_enable_invalidation_messages can result in full catalog refreshes and larger latency and memory spikes.
So avoid judging steady-state catalog behavior immediately after a large schema deployment.
20. Warm Important Workload Paths After Schema Changes
If a deployment invalidates catalog metadata, consider exercising important queries after the deployment but before declaring the application fully warmed.
For example:
This does not eliminate catalog reads; it moves some first-use latency out of the critical user path.
The effect is strongest when combined with long-lived or pooled backend connections.
21. Look at Which Catalogs Are Missing, Not Just the Total Count
A high total miss count tells you there is a problem.
The table breakdown tells you what to do about it.
- ●
pg_operator - ●
pg_amop - ●
pg_cast - ●
pg_proc
may suggest a useful preload list.
Repeated pg_authid activity associated with large numbers of connections points more toward pooling and authentication caching.
Those are different problems with different fixes.
22. Compare Cold and Warm Latency From Every Region
For multi-region systems, run the same experiment from each application region:
Record:
Total latency
Catalog Reads
Catalog Cache Misses
Master Read RPCs
Current Master Leader region
If the warm executions converge while cold executions track WAN latency to the master leader, you have a strong indication that catalog RPC locality is involved.
23. Watch YB-Master CPU as Well as Latency
Catalog cache problems can appear in two different ways:
or:
The official tuning guide specifically calls out high YB-Master leader CPU as a possible result of connection churn repeatedly warming backend catalog caches.
24. Large Numbers of Databases and TServers Deserve Extra Attention
An advanced case is a universe with many databases and/or many YB-TServers.
Each TServer heartbeat carries catalog-version information from YB-Master. YugabyteDB has an enable_heartbeat_pg_catalog_versions_cache master flag specifically intended to reduce repeated reads of pg_yb_catalog_version in such deployments.
This is more specialized than normal catalog-cache tuning, but it is worth knowing about when the topology itself is very large.
25. Don’t Use Manual Master Leader Stepdown as Routine Performance Tuning
yb-admin master_leader_stepdown can force a YB-Master leader change, but the YugabyteDB documentation says to use it only when recommended by Yugabyte Support and warns about possible downtime.
For normal placement policy, use:
set_preferred_zones
rather than building operational procedures around repeated manual leader stepdowns.
What Helps… and What Doesn’t?
A Practical Troubleshooting Order
I would approach a real-world problem in this order:
What About Applications Active in Every Region?
This is where the limitation becomes more important.
There is only one SysCatalog leader at a time. Moving it closer to Region A naturally makes it farther from Regions B and C.
Therefore, for a truly active-active application:
leader placement alone cannot make catalog misses local everywhere.
That makes the other optimizations even more important:
Current State
As of September 2026, the public YugabyteDB documentation describes catalog caching, catalog preloading, connection pooling, YB-TServer response caching, and preferred leader placement as the available mechanisms for reducing this overhead.
It does not currently document a user-facing mechanism for maintaining a separately readable, strongly consistent SysCatalog copy in each region.
Likewise, set_preferred_zones can influence where the single SysCatalog leader resides, but it is not a mechanism for creating one master leader per region.
That distinction is important when designing truly active-active multi-region applications.
Final Takeaway
Cross-region YSQL catalog latency is usually best treated as a cache-miss reduction problem first and a leader-placement problem second.
A warm YugabyteDB backend should satisfy most catalog lookups locally from memory. The goal is therefore to keep backends warm, minimize connection churn, preload the metadata that matters, and avoid unnecessary catalog invalidation.
For the remaining catalog RPCs, set_preferred_zones provides a way to position the SysCatalog leader closer to the primary application region, provided a YB-Master already exists there.
Pool connections, reuse warm backends, preload frequently used catalogs, and cache authentication metadata where appropriate.
Align the SysCatalog leader, YSQL connections, and the application’s dominant region using preferred-zone and topology-aware routing.
Have Fun!
My daughter is getting married next June, but this weekend was all about celebrating with her friends in Jackson Hole.
Nothing says bachelorette party quite like a scenic horseback ride with the Bride Tribe! 🤠💍🐎