How long does an export take?

Every wait below is a median; maxima are shown alongside it where they matter. Each group has only 3 samples, which is far too few to publish a trustworthy p95 or p99, so none is claimed, and nothing here is a concurrency capacity.

1. How long from clicking export to being able to download

Changing format inside one dataset moves the wait far less than changing dataset does.

The measurement is split into five separate clocks, and the tables below break them out:

• Admitted — the request returning a job id: 9.75–15.79 milliseconds.
• Queued — waiting for a background worker to pick the job up. The worst single wait across all 96 exports was 11.45 milliseconds, and every median was under 10.55 milliseconds. The queue is not the bottleneck.
• Executed — fetching the rows, sorting them, writing the file, uploading it and updating the published report. This is 26–97% of the wait from request to downloadable.
• Observed downloadable — the driver polls the job every 100 milliseconds until it first sees it completed. That polling is where the remaining 21–124 milliseconds goes.
• Downloaded — timed separately, pulling the finished file back from storage. It is never folded into the waits above.

These numbers come from a Release build of the API running natively on macOS, talking to its own PostgreSQL and Azurite, going through the real JobReport and shared reports queue rather than calling the renderer directly.

2. Choosing the dataset and the format

At 10,000 rows, picking the wrong dataset costs about 4.9× — picking the wrong format costs far less.

What the format really changes is the size of the file and how long it takes to download, not how long the server takes to build it. TXT pads every column out to a fixed width, so at 10,000 rows the four datasets together come to 25.02 MiB against 2.84 MiB for the same content in CSV — a factor of 8.8×. XLSX compresses and is smallest at 1.24 MiB. Bigger files take longer to fetch: at 10,000 rows the median download was 8.4–13.4 milliseconds for CSV, 22.3–29.3 for TXT and 7.8–10.9 for XLSX.

3. What happens when the input grows ten times

Two different kinds of dataset, two different kinds of growth.

Per-row cost is milliseconds of execution per input row, comparing the CSV export at 1,000 rows with the same at 10,000 rows. Above 1× means each row got more expensive at ten times the size; below it means the fixed costs were spread more thinly. Raw records is the interesting case: its rows actually got cheaper, because at 1,000 rows most of the work was not per-row work at all. The three summary reports have to materialise every row and then match and roll it up in memory, which is why each of their rows costs several times more than a row of the raw export.

4. What the database and the app did while it worked

The cost of producing these files, as measured rather than estimated.

The database figures include the HTTP admission, the status polling, the download and the verification queries. They are not the report builder's SQL time on its own, and at 10,000 rows SQL accounts for 29–55% of execution time depending on the dataset.

5. Every group, one row each

All 24 measured groups behind everything above. Nothing is sampled out.

Each group is 3 measured samples; the 1 warmup is excluded. "Request to downloadable" includes the 100-millisecond polling interval, and "downloaded" is timed separately afterwards. Every output file reconciled against the source data.

6. What this did not test

Being straight about the edges of this test, because they decide what we should not promise yet.

• Larger inputs. Only 1,000 and 10,000 rows were tested. 100,000 rows was not, so this page gives no answer to "how many rows can it handle".
• No old-version comparison. There is a single point, at a21df821, and nothing to compare it against. No speed-up is claimed and this is not the full S5 acceptance run.
• This is not a capacity ceiling. Jobs ran one at a time, so rows per second is a single job's processing rate, not sustainable throughput. Nothing here shows what happens when several people export at once.
• PDF and mixed workloads. Only CSV, TXT and XLSX were measured. PDF reports, catalogue snapshot builds and product imports were not running alongside.
• Harder data. Matching was 100%, one location per job and one record per key throughout. Long text fields, wide 256-column exports, ambiguous codes needing a candidate list and hot products were not covered.
• Our production cloud setup. The API and driver ran natively on a Mac; PostgreSQL and Azurite shared a 4 vCPU / 8192 MiB Podman VM with the development containers. That is a local baseline, not a cloud-sized comparison.
• Nothing was deployed. This run only establishes a baseline for the current version. The later release step was cancelled and nothing was published or rolled back.

7. How to trust this

• Every file was checked line by line. The downloaded CSV, TXT and XLSX were compared row by row on row count, order and every field value (record id, location, submitted code, key, external id, SKU, barcode, product name, quantities, price and the book, counted and variance figures). XLSX went further: the ZIP entries' CRC values and cell values were checked, and the first measured export was downloaded a second time and compared by SHA-256. All 72 measurements passed.
• The input was reconciled too. Before generation, the 10,000-row job's process and quantity-on-hand counts and totals were verified against the database, along with the identity of every record.
• It ran through the real path. A real supervisor in the target organisation, a normal JobReport, the shared reports queue, a blob upload and the published-report update. No platform identity, no permission bypass, no calling the renderer directly, and no fabricated subscription or licence records — entitlements were prepared normally through the payment Simulator.
• Its own database and storage. Containers were created with a random run label, and the 2 resources this run created were checked and removed by exact identity afterwards. The development environment's containers and data were left untouched.
• The sample size is stated, not hidden. 3 measured samples per group, warmups excluded, medians and maxima only, and an explicit statement that a trustworthy p95 does not exist at this sample size.
• Timing came from the system's own records. Queue and execution times are read from timestamps the server persisted, not estimated by the driver; admission, observation and download are timed separately.

Run def26ed0 · version 20261011-exports · code under test a21df821 (with uncommitted changes to the experiment scripts) · measured 2026-10-11 · 1.69 minutes end to end, including build, setup and cleanup · fixed catalogue of 10,000 products, 100% matching. Every figure on this page was generated by tests/performance/20261011-exports/page.mjs from the measured result files in tests/performance/20261011-exports/reports; none is typed in by hand.