Metadata caching: the one place where the inequality is not close

Why is metadata the best caching deal, and in what currency is each kind of stale metadata paid?

Work the four quantities for a table's schema, file listing and statistics.

• λ_eff is not one query's reuse. It is every query against the object, because every one resolves the schema, lists the files and consults the statistics before doing any work.
• The number of dependencies n is one: the table's own commit.
• P is trivial.
• S is large for a reason that compounds: the metadata round trip sits in the serial fraction of every query, the part that cannot be run in parallel. By Amdahl's Law (the speed-up of a job is limited by its serial part), it caps short-query latency outright. A 200 ms catalog round trip on a 300 ms query is 200/300 = two thirds of the response time, and adding compute does nothing to it.

So λ/w is enormous and P/S is tiny. The inequality passes by orders of magnitude, not by a margin you need to measure. Metadata is the only place here where you do not need the instrumentation of What makes data cacheable to know the answer. It is also the honest reason table formats exist: replacing a directory LIST operation with a manifest was the same optimization done one level down.

The three kinds of metadata then diverge sharply, because staleness is paid in a different currency for each.

Schema: staleness paid in correctness

DDL (schema changes) is rare, so w is tiny and hit rate is superb. But a stale schema does not slow a query down. It misreads the bytes: wrong column, wrong type, silently. This is the clearest case here where staleness becomes a correctness failure rather than a performance one. The mitigation lives elsewhere: ID-based column resolution. If columns are identified by a permanent ID instead of by name or position, a stale name-to-position mapping is harmless, because the cached identity is no longer the thing that changed. (This is "early binding by ID instead of by name", which exists partly to make this cache safe.)

File listings: staleness paid in absence

A stale listing omits new files, so the query returns a result that is correct as of an earlier snapshot. The design pattern to take away from this whole article is:

Manifests are immutable and named by snapshot, so cache their contents forever and put a short TTL on the single snapshot pointer alone. Every good design here has this shape, including the version fingerprints above and the versioned keys of Keeping it honest.

The pointer is one designated cell speaking for everything below it, which is also what lets the cached listings agree with each other; per-entry TTLs would keep each entry fresh but give up that agreement (One designated cell for many entries).

Statistics: staleness paid in plans

Stale statistics (row counts, value distributions) give a correct answer through a wrong plan, and the cost is discontinuous: a plan flip is a cliff, not a slow drift. The direction of the error matters, and no TTL controls it. Statistics that are stale in the direction of underestimating cardinality produce the catastrophic failures: a hash-join build side that exceeds its memory grant, or a broadcast of a table that has since grown. Overestimates merely produce conservative plans. And since cardinality errors compound multiplicatively up a join tree, a stale statistic at a leaf is amplified exponentially with depth.

The conclusion is counterintuitive and correct: the escape from stale statistics is not fresher statistics. It is a plan that does not trust them. That means adaptive execution (the engine checks actual row counts while running and changes plan). It is the right answer because the alternative, driving w to zero for statistics, costs a full scan per refresh and still leaves you exposed between refreshes. Note also that caching statistics stacks an approximation on an approximation: the estimator was already a conservative sketch (a sound approximation), and caching adds staleness underneath it. This article owns only the second term.

In one sentence: λ is every query and n is one, so metadata is the best deal here, and its staleness is billed in three currencies: correctness for schema, absence for listings, plan quality for statistics.