An endpoint stays inside its statement budget yet is slow and heap-heavy under load - how would over-fetching explain that?

## Why a statement budget misses this Counting statements is a good guard against one failure mode: a read that repeats itself per row. It is blind to a second, independent one: a read that is simply too wide. One statement that returns 300 columns across 5,000 rows scores exactly as well as one statement that returns 3 columns across 20. The budget is measuring round trips, and the problem is in the payload. That is why over-fetch tends to be found late. Nothing in the usual dashboard is red; the endpoint is merely slower than it should be, and the service uses more memory than anyone can explain. ## The shapes over-fetch takes | Shape | What it looks like | Why it happens | |---|---|---| | Whole graph for one field | a read materialises an object and its links to display a name | a mapping default nobody revisited, or a plan reused from a heavier caller | | Wide rows | every read carries large text or binary columns | the value is mapped inline on the object, so it rides along with every load | | Unbounded collection for a count | the collection is loaded so its size can be read in memory | the count is a property of the collection object, so it looks free | | Transitive links | fetching one link pulls the links it declares | eager chains through the graph without anyone asking | The last two are the most expensive per line of code. A count taken from a materialised collection scales with the collection; an aggregate over the same rows in the database returns one number. ## What the bytes actually cost The expense is not only the wire. 1. **Transfer.** More columns and more rows, on every call. 2. **Buffering in the driver.** A large result may be assembled in memory before the layer sees it. 3. **Hydration.** Every returned row becomes objects: allocation, field population, identity-map insertion. 4. **Change tracking.** Objects in the tracked set are held for the life of the unit of work and inspected when changes are flushed, so a read that materialises ten times what it needs makes the write path work harder too. 5. **Heap and garbage collection.** Allocation rate rises, pause frequency rises with it, and under concurrency the peak footprint is per-request, not per-endpoint. 6. **Database-side working set.** Reading wide rows pulls pages into the engine's buffer pool, evicting data other queries wanted. Item 5 is the one that turns a mild inefficiency into an incident: over-fetch is multiplied by concurrency, so a page that is merely fat in a test becomes a memory event under real traffic. ## How to confirm it rather than guess - **Compare materialised to used.** Count the objects the read built and the columns it returned, then count what the response actually contains. A large ratio is the finding. - **Measure the payload, not the count.** Bytes returned per call, and result-set width, alongside statement count. - **Watch the memory shape.** Allocation per request and post-collection heap after exercising the endpoint tell you whether the read is the source. - **Look for a step change.** An endpoint that slowed sharply without a code change often gained a column: a large value added to a table that every read of the object already pulls. - **Read the mapping, not just the query.** When the query text does not explain the width, the fetch instruction is somewhere else. ## Remedies that belong to the fetch decision Staying with the loading question itself, the levers are: - **Remove the mapping-level default that nobody needs**, and let the reads that do need the link ask for it. - **Size the plan to the use case** rather than reusing the widest one that exists. - **Answer aggregate questions with an aggregate.** `SELECT COUNT(*) FROM line_item WHERE order_id = ?` returns a number; materialising the collection returns the rows. - **Bound what a collection fetch may bring back** - page it, or refuse to fetch it whole in a plan. - **Store a large value outside the row it is logically attached to**, mapping only a reference, so the payload is fetched when a use case asks for it and never by default. Returning a narrower shape than the mapped object is another lever entirely, and a strong one, but it changes what the read returns rather than how much of the graph it pulls. ## The habit worth keeping Treat "how many statements" and "how much data" as two separate budgets with two separate guards. A team that only tracks the first will keep shipping reads that are correct, tidy, singular - and quietly move megabytes per request.