Optimizing Large Data Queries in Salesforce

𝗦𝘁𝗼𝗽 𝗖𝗵𝘂𝗻𝗸𝗶𝗻𝗴 𝗬𝗼𝘂𝗿 𝗗𝗮𝘁𝗮 𝘁𝗵𝗲 𝗢𝗹𝗱 𝗪𝗮𝘆 – 𝗔𝗽𝗲𝘅 𝗖𝘂𝗿𝘀𝗼𝗿𝘀 𝗮𝗿𝗲 𝗚𝗔! 🚀 Salesforce just moved Apex Cursors to Generally Available (GA) in the Spring ’26 release, and it informs how we handle high-volume data processing and UI pagination. If you’ve been relying on Batch Apex or fighting SOQL OFFSET limits, it’s time to rethink that design.   𝗧𝗵𝗲 𝗦𝗵𝗶𝗳𝘁: 🔹 𝗕𝗲𝗳𝗼𝗿𝗲: The “SOQL OFFSET” for UI Pagination The Pain:   • Hard limit at 2,000 records. Query fails beyond this point  • Inconsistent pagination when records are added/deleted between fetches  • Duplicates/missing records as one navigate pages 𝗡𝗼𝘄: Use the 𝙿̲𝚊̲𝚐̲𝚒̲𝚗̲𝚊̲𝚝̲𝚒̲𝚘̲𝚗̲𝙲̲𝚞̲𝚛̲𝚜̲𝚘̲𝚛̲ class  • Supports up to 100,000 rows  • Max 2,000 rows per page fetch  • Consistent page results even if underlying data changes between fetches  • Server-side cursor state eliminates offset calculation issues 𝗧𝗶𝗽: If you need truly stateless pagination, consider 𝘬𝘦𝘺𝘴𝘦𝘵 𝘱𝘢𝘨𝘪𝘯𝘢𝘵𝘪𝘰𝘯 (̲𝚆̲𝙷̲𝙴̲𝚁̲𝙴̲ ̲𝙸̲𝚍̲ ̲>̲ ̲:̲𝚕̲𝚊̲𝚜̲𝚝̲𝙸̲𝚍̲)̲ instead. 𝙿̲𝚊̲𝚐̲𝚒̲𝚗̲𝚊̲𝚝̲𝚒̲𝚘̲𝚗̲𝙲̲𝚞̲𝚛̲𝚜̲𝚘̲𝚛̲ maintains server-side state, but keyset pagination is fully stateless. It lets the client hold the bookmark (last record’s ID/CreatedDate)   🔹 𝗕𝗲𝗳𝗼𝗿𝗲: Rigid Batch Apex (Start/Execute/Finish) The Pain:  • Heavy boilerplate with start/execute/finish lifecycle  • Complex state management across batches  • Difficult to chain diverse tasks without custom state handling  • Fixed batch execution model 𝗡𝗼𝘄: Combine Apex Cursors + Queueable Apex  • Fetch up to 50 million rows per standard cursor  • 𝗖𝗿𝗶𝘁𝗶𝗰𝗮𝗹 𝗰𝗵𝘂𝗻𝗸𝗶𝗻𝗴 𝘀𝘁𝗿𝗮𝘁𝗲𝗴𝘆:    • Limited to 10 fetch calls per transaction (to prevent anti-patterns like 1,000 tiny fetches)    • Typical approach: Fetch manageable chunks (e.g., 50K rows per fetch) to respect heap limits    • Example: 10 fetches of 50K rows = 500K rows per Queueable, then chain to next job    • For 50M rows, chain ~100 Queueable jobs, each processing 500K rows safely  • Serialize and pass cursor state between chained Queueable jobs  • More modular, flexible architecture with less overhead  • No need to manage complex state variables   🔹 𝗕𝗲𝗳𝗼𝗿𝗲: Generic Try-Catch Error Handling The Pain:  • Hard to distinguish temporary vs. fatal failures  • No built-in retry guidance for cursor operations 𝗡𝗼𝘄: Use specialized exceptions  • 𝙵̲𝚊̲𝚝̲𝚊̲𝚕̲𝙲̲𝚞̲𝚛̲𝚜̲𝚘̲𝚛̲𝙴̲𝚡̲𝚌̲𝚎̲𝚙̲𝚝̲𝚒̲𝚘̲𝚗̲: Permanent failure. Don’t retry  • 𝚃̲𝚛̲𝚊̲𝚗̲𝚜̲𝚒̲𝚎̲𝚗̲𝚝̲𝙲̲𝚞̲𝚛̲𝚜̲𝚘̲𝚛̲𝙴̲𝚡̲𝚌̲𝚎̲𝚙̲𝚝̲𝚒̲𝚘̲𝚗̲: Temporary issue. Safe to retry  • Enables smarter, resilient retry logic   𝗕𝗲𝗻𝗲𝗳𝗶𝘁𝘀 ✅ Better performance – Incremental fetching avoids memory overload ✅ Higher limits – 50M rows for standard cursors, 100K for pagination ✅ Smoother UX – Consistent pagination in data-heavy LWCs ✅ Cleaner code – Less boilerplate than Batch Apex ✅ AuraEnabled support – Pass cursors between LWC and Apex seamlessly

Processing huge Salesforce datasets just got a serious upgrade ⚙️ Spring ’26 makes Apex Cursors GA — and they’re a far better fit than Batch Apex for many real-world jobs. 🔥 Why it matters • Stream large SOQL results in chunks • Jump forward/backward from any position • Serialize + pass through Queueables • Enable clean LWC pagination without re-query hacks 💡 Compared to Batch Apex Batch: fixed sizes, one-directional, rigid Cursors+Queueable: flexible chunks, bidirectional, fine-grained control 📈 Practical wins • ETL-style async processing without heavy frameworks • Smarter limit usage • Cleaner UI patterns • Less code, more control Limits still apply — but you manage them instead of fighting them. This is a big quality-of-life win for devs dealing with large data volumes, async chains, and pagination-heavy UIs. Read more: https://lnkd.in/dwSBCAbP #Salesforce #Apex #Spring26 #Async #Developers #EnterpriseTech #LWC #DataEngineering