Salesforce runs customer code on shared multitenant infrastructure. To keep one transaction from monopolizing platform resources, Apex enforces governor limits on database queries, DML, CPU time, heap, callouts, rows, and other operations. For a Salesforce Platform Developer<\/a>, understanding those limits is architectural knowledge: code that works for one record but fails for a real batch is not production-ready.<\/p>\n Performance and governor limits are related but not identical. The broader Salesforce certifications<\/a> ecosystem treats efficient platform use as a design responsibility rather than an after-the-fact optimization. Code can stay under every formal limit and still be slow. The goal is efficient, bounded work that scales with transaction size and uses the platform’s asynchronous and declarative capabilities appropriately.<\/p>\n Developers should distinguish per-transaction limits from org-wide or asynchronous allocations. A design may pass unit tests yet fail in production because many concurrent users or scheduled jobs consume broader resources. Start with the transaction limits that shape Apex code, then understand the platform allocations relevant to integrations, events, async jobs, and APIs used by the application.<\/p>\n Governor limits protect the multitenant environment. A synchronous transaction receives a finite budget of queries, DML, CPU, heap, and other resources. When certain limits are exceeded, Salesforce raises a runtime exception that ordinary error handling cannot rescue.<\/p>\n This model makes resource use part of correctness. Developers need to know where database work occurs and how many times it can repeat.<\/p>\n Bulkification reduces query count, but a single poorly filtered query can still be expensive. The goal is not merely staying below the numeric SOQL limit; it is retrieving a bounded, relevant data set. Query planning becomes more important as tables grow because a filter that is fine with ten thousand records can become costly with tens of millions.<\/p>\n If a loop processes two hundred records and issues a query for each one, the code can exhaust query limits quickly. The same applies to DML statements. Gather identifiers, query once, organize data in Maps, and perform grouped DML.<\/p>\n The scalable-design principles in scalability<\/a> apply directly to Apex: work should grow predictably instead of multiplying database calls per record.<\/p>\n CPU problems often reveal algorithmic issues. Nested loops over two large collections can create quadratic work even without extra database calls. Convert one collection into a Map or Set so matching becomes direct. The best optimization is frequently a better data structure rather than a platform-specific trick.<\/p>\n CPU limits can be consumed by nested loops, expensive transformations, repeated formulas, recursion, and chains of automation. A transaction with modest query counts can still fail if code repeatedly scans large collections or triggers multiple rounds of updates.<\/p>\n Profile before guessing. Debug logs, transaction analysis, and targeted tests can show where time is spent. Reducing unnecessary work is usually more valuable than micro-optimizing syntax.<\/p>\n Serialization also consumes resources. Returning huge object graphs to LWC or processing large JSON messages can strain heap and CPU even when the underlying query is efficient. Define small DTOs or response structures containing only what the client requires, and paginate or segment large datasets instead of transferring everything at once.<\/p>\n Large query results, JSON payloads, files, and in-memory data structures consume heap. Avoid loading more fields and records than the operation requires. Stream or segment large workloads when possible rather than building one enormous structure.<\/p>\n General performance ideas from memory-conscious programming<\/a> transfer conceptually even though Apex uses different language features: do not hold unnecessary data merely because it is convenient.<\/p>\n Asynchronous Apex should preserve idempotency because retries or chained jobs can revisit work. Store enough state to know what was processed, avoid creating duplicate side effects, and design batch scopes so one failed chunk does not corrupt unrelated records. Moving work to a queue changes timing, not the need for deterministic logic.<\/p>\n Queueable, Batch Apex, Scheduled Apex, and other asynchronous techniques can move long-running or non-interactive work out of the user’s transaction. They also provide different limits and execution characteristics.<\/p>\n Asynchronous processing is not a license to ignore efficiency. It should be used when the work genuinely benefits from a separate transaction, not as a way to hide poorly designed synchronous code.<\/p>\n Selective queries can be supported by indexes, external IDs, and data-model choices. When a use case repeatedly filters on a large nonselective field, the problem may belong in schema design rather than code tuning. Developers should collaborate with administrators and architects before adding increasingly complex query workarounds.<\/p>\n Large orgs make query selectivity important. Filters should narrow result sets meaningfully, and developers should understand how indexed fields and query plans affect expensive operations. Querying every field or every historical record increases both response time and heap.<\/p>\n When data access is the bottleneck, changing the algorithm or data model can matter more than changing Apex syntax.<\/p>\n Automation inventories are useful performance artifacts. List triggers, record-triggered Flows, validation rules, rollups, managed-package automation, and integrations for the affected object. When a transaction becomes slow, this map shows where work accumulates. Without it, teams tend to optimize whichever component they can see first rather than the true bottleneck.<\/p>\n A trigger may execute alongside Flows, validation rules, managed-package logic, rollups, and other code. Repeated record updates can create transaction chains that are hard to see from one class. Developers should inspect the whole automation path.<\/p>\nLimits exist because the runtime is shared<\/h3>\n
SOQL and DML inside loops are classic failure patterns<\/h3>\n
CPU time often reveals hidden complexity<\/h3>\n
Heap and payload size matter when processing large data sets<\/h3>\n
Asynchronous Apex changes the transaction boundary<\/h3>\n
Selective queries and indexes improve database performance<\/h3>\n
Automation architecture affects code performance<\/h3>\n