Which memory limit actually isolates RocksDB column families sharing a block cache?

RocksDB lets several column families live inside one database instance, and each family keeps its own memtable and SST files. Memtable memory can be bounded globally through a WriteBufferManager, while the block cache is usually shared across families unless a separate cache is assigned per column family.

The unresolved part is how these two layers interact. A per-family write buffer limit constrains flush-triggered memory, but it does not obviously constrain how much of a shared block cache one family's reads or scans may occupy. Under concurrent write and read load, eviction can appear to ignore the per-family budgets that were configured.

Assume RocksDB 7.x–8.x option names, and treat the behavior as needing verification against the exact release in use.

Specific questions: When column families share a single block cache, does a WriteBufferManager limit provide meaningful memory isolation, or only delay stalls? Which knobs — per-family block cache priority, cache_index_and_filter_blocks, or separate caches — make that isolation observable? Which statistics distinguish memtable pressure from block cache churn?