an unfiltered backfill keeps every block of its car, the records from the walk and the repo's write batch until it commits, so its peak follows the car's size (about 4.5x to 6.3x the car on the bench repos) and nothing bounded the sum: the ceiling was max_car_body_bytes times the backfill concurrency, 2 GiB x 16 by default. streaming can't shrink it, since that path keeps every block by design. whole-car backfills now take a share of a byte budget, HYDRANT_BACKFILL_MEMORY_BYTES (4 GiB by default), sized as the car times the larger peak ratio measured (6.3, jay.bsky.team). the share grows as the body arrives, or all at once from content-length, and is held until process_did returns, so past the batch commit where the peak is. it's an RAII guard, so error, timeout and cancel paths give it back. it's taken last, after the backfill permit, the pds admission and the pds connection permit, so a task waiting on it holds nothing a holder needs. the oldest reservation never waits and may go over the limit, because shares grow in steps and two big repos could otherwise each hold part of the budget and wait on each other forever. so the bound is the budget plus one repo. filtered backfills stream and keep only what they want, so they don't take a share. 4 GiB lets the usual repo of a few hundred kilobytes and 16 or 64 of them at once never notice it, holds a few repos the size of the biggest accounts at once, and still bounds a laptop and the full network box alike. tests and what breaks them: two_growing_backfills_bigger_than_the_budget deadlocks (times out) without the oldest-goes-over rule. small_backfills_never_wait_on_the_default_budget fails with a 1 MB default. a_whole_car_that_fails_partway_gives_its_budget_back fails (321 bytes left) when a failed read leaks its share. a_full_backfill_holds_its_budget_until_its_batch_commits fails (0 held) when process_did drops the share right after the fetch.