Skip to main content
Applies to: Embedded ❌, Enterprise ✅ The data page cache holds fixed-size pages of raw table data read from object storage, keyed by their location, so a later read of the same range is served from memory or local disk instead of round-tripping to the backing store. Plan executors and query nodes each keep their own cache for the pages they serve. A background prewarm job can populate a cache ahead of a request that needs it, rather than filling it lazily on first read. See Architecture.
A table’s local disk cache shares one configurable budget with the tiered index cache’s disk tier where both are enabled on the same executor.

​
Why it matters

Object storage is durable and cheap, but every round trip to it adds latency and egress cost. For workloads that read the same ranges repeatedly — a hot subset of embeddings, a frequently-filtered column — the data page cache turns most of those reads into local memory or disk hits instead, so performance stays predictable as traffic grows and you pay object storage once per page, not once per read. Contact us to learn more about how caching is sized and tuned for your workload.

​
Cache interfaces

  • Tiered Index Cache for the related cache that holds deserialized index structures instead of raw data pages.
  • Query plans for inspecting what a query actually read.