Governor limits get talked about like a ceiling you eventually bump your head on. In practice, they're closer to a stress test — an org that regularly hits them almost always has a design issue upstream, not an unlucky brush with Salesforce's multi-tenant infrastructure.
The limits that actually bite
- 100 SOQL queries per synchronous transaction (200 for asynchronous) — this is the one that catches people doing a query inside a loop.
- 10,000 ms of CPU time per synchronous transaction, 60,000 ms for asynchronous Apex (Batch, Queueable, @future, Scheduled) — the gap between the two is a strong hint about when to move logic off the main thread.
- 150 DML statements per transaction, and a 6 MB heap size — both of which get tight fast if bulkification isn't built in from the start.
- 100 callouts per transaction — usually the constraint that surfaces when an integration was designed as "call the API once per record" instead of batched.
Why orgs actually hit them
- Queries or DML inside a for-loop instead of bulkified — the single most common root cause, and almost always fixable without a rebuild.
- Triggers stacking on top of triggers across years of "quick fixes," each one assuming it's the only thing running.
- Automation built for one record at a time, never tested against a bulk data load or integration batch.
- No single owner of trigger order and execution context, so nobody notices the org is accumulating risk until a batch job fails.
What good architecture actually looks like
- Bulkified triggers and a single trigger-per-object pattern, so execution order is predictable instead of accidental.
- Async processing (Queueable/Batch) for anything that touches more than a handful of records or an external callout.
- Selective queries with indexed filters, not "query everything and filter in Apex."
- Regular load testing against realistic data volumes — not just the sandbox's 200 sample records.
The connection to maintainability
This is the same principle behind our Manufacturing case study: an architecture redesigned around real business-function objectives, built to stay inside governor limits and configurable enough that the client's own team could maintain it after we left. Staying inside the limits isn't a constraint you design around after the fact — it's what disciplined bulkification and clean trigger architecture give you for free.
Read the Manufacturing case study →
Sources referenced for this post
- Apex Hours — "Governor Limits in Salesforce & Best Practices"
- SF Dictionary — "Salesforce Governor Limits Cheat Sheet 2026"
- Clientell AI — "What Are Governor Limits in Salesforce? Complete Guide (2026)"