SAP OData Pagination and Extraction Time Calculator
Pulling hundreds of thousands of rows through OData is a classic integration task, and the page size you pick decides whether it takes ten minutes or two hours. This tool shows the trade-off between call overhead and response size.
Your numbers
Network round trip, authentication, request parsing and query start-up.
Database read, mapping and serialization cost per row. Measure with two page sizes to estimate it.
Concurrent requests. Keep within what the Gateway and backend can serve.
Your results
Ideal model. Real services may cap $top, slow down on deep $skip offsets, or throttle parallel requests, so benchmark on your system.
Total extraction time (min) vs page size
Sweeps Page size ($top) from 50 to 5000, holding your other inputs fixed.
SAP data extraction review
Optional: a review of your extraction design for load, correctness and security.
Optional. The tool and every export work without this. No spam.
How to use it
Enter the number of records you must read and the page size you plan to request with $top. Estimate the fixed cost per call and the cost per record by timing two requests with different page sizes against the real service, then solving for the two numbers. Add the average payload per record and the number of threads. The tool returns call count, time per call, payload per call and total time.
What the model assumes
Each call costs a fixed overhead plus a per-record cost, so larger pages amortize the overhead. Parallel threads divide the elapsed time under the assumption that the server scales linearly. In reality returns diminish: very large pages raise memory use and timeouts, deep $skip values can force the database to read and discard earlier rows, and services using server-driven paging return a next link with a page size you do not control. Prefer filtering by a key range or change timestamp when you need many pages.
Reading the chart
The curve drops quickly as page size rises from small values, then flattens. Beyond the knee, extra page size gives little gain but increases response size and risk. Choose a size near the knee, then raise threads only while the backend and Gateway stay healthy. Check the Gateway error log with transaction /IWFND/ERROR_LOG and the backend load before pushing parallelism.
Common mistakes
Extracting a very large dataset with $skip pagination while data changes can skip or duplicate rows, because the order is not stable unless you specify $orderby on a unique key. Another mistake is running a daytime bulk extract on a productive Gateway shared with user-facing apps. For genuinely large loads, consider a delta mechanism, CDS-based extraction or a dedicated replication tool instead of OData.
Frequently Asked Questions
What is a good OData page size for SAP?
There is no universal value. Many teams land between 500 and 5000 records depending on row width. Measure on your service, find where the time curve flattens and stay below any server limit on $top.
Why does $skip get slow?
The database may have to read and discard all skipped rows, so later pages cost more than early ones. Filtering on a key range avoids this and is stable even if rows are added.
Can I use $batch?
Yes, a batch groups several requests into one HTTP call and cuts network overhead, but each sub-request still costs server time. It helps most when latency dominates.
How many parallel threads are safe?
Start with two to four and watch work process usage and response times. Increase only if the backend has spare capacity, and agree the window with your Basis team.
If you need a governed, read-only data feed out of SAP for analytics or AI, Netray can help design extraction that respects SAP roles and system load.
Related Tools
SAP CPI Monthly Message Volume and Cost Calculator
Forecast monthly Cloud Integration message volume and cost per interface so you can budget before volumes surprise you.
SAPSAP RFC Connection Pool Sizing Calculator
Calculate the concurrent RFC connections an external application needs and compare them with gateway and destination limits.
SAPSAP Interface Retry and Backoff Window Calculator
See how long an interface keeps retrying before it gives up, using initial delay, multiplier, retry count and jitter.
SAPSAP IDoc Processing Work Process Sizing Calculator
Work out how many work processes inbound IDoc processing needs at peak, and what throughput your current setup can sustain.