Table of Contents

Resources & budgets

In one line: a live utilization map of the engine — enough real-time data to see pressure building and throttle before you hit a limit, instead of meeting the ceiling as an exception.

You set the budgets once, at startup, through ResourceOptions — page-cache size, max active transactions, WAL ring/segment sizing, checkpoint thresholds — and Validate() checks that the fixed allocations actually fit the total. From then on every significant resource (page cache, transactions, WAL, allocators, timers, …) sits in a fixed tree and reports its own utilization. Reporting is pull-based: metrics are read when you take a snapshot, never pushed on the hot path — so having the map costs nothing while you aren't looking at it.

Why this earns a page: a budget is a ceiling, and hitting one isn't negotiable — it surfaces as a ResourceExhaustedException. The graph is what lets you not get there: it says how close you are right now, so you can shed load, slow your input, or throttle while there's still room. And when something does saturate, FindRootCause matters more than the raw number — the node that looks busiest is usually a symptom, so it walks the dependency chain back to whatever is actually backed up, letting you throttle the right thing instead of guessing.

⚠️ The engine does not auto-throttle off this graph. Overload management reacts to tick overrun, not resource metrics — separate signals. This graph is the data; acting on it (health checks, alerts, shedding) is the host's job. Related caveat: ExhaustionPolicy currently documents intent rather than switching behaviour at runtime.

How it relates

In the API

Learn & use