Small-data code is a trap
Apex that queries or performs DML inside a loop passes every test on a handful of records and then hits governor limits the moment real volume arrives. The failure is not random; it is the predictable result of per-record work that should have been done in bulk.
On an org moving tens of millions of records, code that is not bulk-safe does not degrade gracefully. It stops.
Bulkify by default
The habit is to write every trigger and job as if it will always receive the maximum batch: collect ids, query once outside the loop, build collections, and do DML in bulk. Selective, indexed queries keep SOQL within limits, and batchable or queueable jobs handle volumes a single transaction cannot.
None of this is advanced. It is simply assuming volume from the start rather than retrofitting it after the first production failure.
Prove it against real shapes
Bulk-safety has to be tested against production-like data, not three hand-made rows. We seed sandboxes with realistic, connected data so a job meets the hierarchies and edge cases it will actually face, and we test at volume before it ships. Code that has met real shapes in a sandbox does not surprise you in production.
Key takeaways
- Query-in-loop and DML-in-loop code passes tests and fails at real volume.
- Bulkify by default: query once, work in collections, batch large jobs.
- Test bulk-safety against realistic seeded data, not a handful of rows.