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.
What works better (more stable patterns):
Stop using deep offsets. Page by ObjectID instead.
First get OID stats: returnIdsOnly=true (or returnCountOnly=true + orderByFields=OBJECTID).
Then query in chunks like: where=OBJECTID > x AND OBJECTID <= y with orderByFields=OBJECTID and resultRecordCount=2000.
This avoids the “skip N rows” penalty that kills performance after a couple million.
Use asynchronous extract instead of raw query when you can.
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.
Parallelize carefully (only if needed).
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.
Tune for reliability.
Use POST (not GET) for long params, set timeouts/retries with backoff, and request only needed fields (outFields) + returnGeometry=false unless required.
