https://community.esri.com/t5/arcgis-rest-apis-and-services-questions/performance-degradation-amp-timeout-during-large/m-p/1674897#M5073 <P>Yes—what you’re seeing is common at this scale. There isn’t an official “2M hard limit,” but very large sequential resultOffset paging gets progressively slower and can start failing (timeouts/“invalid query”) because the service still has to scan/skip more rows as the offset grows, and AGOL also enforces fair-use throttling under sustained high-volume pulls.</P><P>What works better (more stable patterns):</P><P>Stop using deep offsets. Page by ObjectID instead.</P><P>First get OID stats: returnIdsOnly=true (or returnCountOnly=true + orderByFields=OBJECTID).</P><P>Then query in chunks like: where=OBJECTID &gt; x AND OBJECTID &lt;= y with orderByFields=OBJECTID and resultRecordCount=2000.</P><P>This avoids the “skip N rows” penalty that kills performance after a couple million.</P><P>Use asynchronous extract instead of raw query when you can.</P><P>Prefer Extract Data / Create Replica (sync/replica workflow) for big exports—those are designed for bulk movement and tend to be more resilient than millions of /query calls.</P><P>Parallelize carefully (only if needed).</P><P>If you parallelize, split by OID ranges (or time slices) and keep concurrency modest (e.g., 3–8 workers). Too much parallelism will trip throttling faster.</P><P>Tune for reliability.</P><P>Use POST (not GET) for long params, set timeouts/retries with backoff, and request only needed fields (outFields) + returnGeometry=false unless required.</P> Thu, 25 Dec 2025 19:15:49 GMT VenkataKondepati 2025-12-25T19:15:49Z https://community.esri.com/t5/arcgis-rest-apis-and-services-questions/performance-degradation-amp-timeout-during-large/m-p/1674834#M5072 <P>Hello Community,<BR />​We are encountering a significant performance bottleneck when performing large-scale data extraction from a Hosted Feature Service (approx. 8.8 million records) via the ArcGIS Online REST API.<BR />​The Issue:<BR />We are using standard pagination (resultOffset and resultRecordCount) with a batch size of 2,000.<BR />​0–2M Records: Requests are stable and performant.<BR />​~2M+ Records: Response times increase significantly.<BR />​3M–3.5M Records: The API begins returning timeouts and "invalid query" errors, despite the query parameters being consistent with previous batches.<BR />​Question:<BR />​Is there a known platform-level "cumulative query constraint" or throttling mechanism for very high-volume extractions in a single session?<BR />​Are there recommended patterns for this scale? (e.g., Would parallelizing queries across different ObjectID ranges or using the Extract Data tool via Geoprocessing be more stable than raw REST pagination?)<BR />​Technical Details:<BR />​Service Type: Hosted Feature Service (ArcGIS Online)<BR />​Auth: OAuth 2.0 / User Token<BR />​Method: GET / POST via /query endpoint</P> Wed, 24 Dec 2025 12:16:44 GMT https://community.esri.com/t5/arcgis-rest-apis-and-services-questions/performance-degradation-amp-timeout-during-large/m-p/1674834#M5072 ÁdhavanBalakrishnan 2025-12-24T12:16:44Z https://community.esri.com/t5/arcgis-rest-apis-and-services-questions/performance-degradation-amp-timeout-during-large/m-p/1674897#M5073 <P>Yes—what you’re seeing is common at this scale. There isn’t an official “2M hard limit,” but very large sequential resultOffset paging gets progressively slower and can start failing (timeouts/“invalid query”) because the service still has to scan/skip more rows as the offset grows, and AGOL also enforces fair-use throttling under sustained high-volume pulls.</P><P>What works better (more stable patterns):</P><P>Stop using deep offsets. Page by ObjectID instead.</P><P>First get OID stats: returnIdsOnly=true (or returnCountOnly=true + orderByFields=OBJECTID).</P><P>Then query in chunks like: where=OBJECTID &gt; x AND OBJECTID &lt;= y with orderByFields=OBJECTID and resultRecordCount=2000.</P><P>This avoids the “skip N rows” penalty that kills performance after a couple million.</P><P>Use asynchronous extract instead of raw query when you can.</P><P>Prefer Extract Data / Create Replica (sync/replica workflow) for big exports—those are designed for bulk movement and tend to be more resilient than millions of /query calls.</P><P>Parallelize carefully (only if needed).</P><P>If you parallelize, split by OID ranges (or time slices) and keep concurrency modest (e.g., 3–8 workers). Too much parallelism will trip throttling faster.</P><P>Tune for reliability.</P><P>Use POST (not GET) for long params, set timeouts/retries with backoff, and request only needed fields (outFields) + returnGeometry=false unless required.</P> Thu, 25 Dec 2025 19:15:49 GMT https://community.esri.com/t5/arcgis-rest-apis-and-services-questions/performance-degradation-amp-timeout-during-large/m-p/1674897#M5073 VenkataKondepati 2025-12-25T19:15:49Z