Measured, not estimated
Benchmark
These are the only performance numbers we publish, and each one carries the conditions it was measured under. We do not extrapolate from them, and neither should you.
Read this before the numbers
In every test below, both the source and the destinations were on local hardware — a USB stick reading, internal SSDs writing. These figures measure the engine, not a real-world job on your cards, your reader and your drives. A CFexpress card on a Thunderbolt reader writing to a RAID will behave differently, and we have not measured that, so we will not tell you what it does.
You cannot derive 100 GB in X minutes
from anything on this page. If a vendor lets you do that arithmetic with their numbers, be suspicious of the numbers.
A full job, end to end
Measured 22 August 2026. Source: USB stick. Destinations: two folders on the internal SSD. Verification by read-back was enabled, as it always is.
Where that time actually went
| Phase | Data | Time |
|---|---|---|
| Reading the card (once) and writing both destinations | 1.09 GB read | 56.5 s |
| Flushing devices, then reading every file back from both destinations | 2.18 GB re-read | 10.4 s |
| Total | 67.1 s |
Re-reading and verifying 2.18 GB from the destinations cost roughly a sixth of what it cost to read 1.09 GB from the card. That is the whole argument for reading the card once: the expensive device is the one you should touch least.
Adding destinations is cheaper than it sounds
Same 22 August 2026 test rig. Local destinations; a network destination would not behave like this.
Three copies do not take three times as long, because the card is still only read once. The extra cost is writing and verifying, which is the cheap half of the job.
A second, smaller run
| Files | Size | Destinations | Time | Measured rate |
|---|---|---|---|---|
| 121 | 633.6 MB | 2 | 7.9 s | 80.7 MB/s |
That 80.7 MB/s is the rate this run achieved on that stick. It is not a specification, it is not a promise, and it will not be what your reader does.
The test that matters more than the timings
We physically pulled the card out, mid-copy
Not a simulated failure, not a killed process: the stick was yanked out of the port while an offload to three destinations was running. The test was repeated.
- 937 files across three destinations were byte-for-byte identical to the source
- 0 partial files — not one truncated, not one half-written
- Confirmed with an external comparison tool, not with our own checksums, because checking our work with our own arithmetic proves nothing
The engine has also survived being killed outright with SIGKILL in the middle of a job, with the same result: whatever is on disk is either complete and verified, or clearly marked as not a backup.
Performed 22 August 2026, twice, on the local test rig.
This is the number we would want to see from someone else's software, and it is the one nobody publishes. An offloader that is fast when everything goes right is not interesting. What it does when the card comes loose at the wrong moment is the entire product.
What we deliberately do not tell you
- How long your card will take. We have not measured your hardware.
- That we are faster than any competitor. We have not run their software on the same rig, so we have no basis to say it.
- Throughput figures for network destinations. Not measured yet, so not published.
- Anything derived by multiplying the numbers above. Rule one of this product: no performance claim that was not measured, in the app or on this site.