Measure the transfer your files actually need.
Upload a file through the real Elara Send path, wait for storage verification, then stream the original back and check every byte. No desktop application or decoder is required.
Run a real browser round trip.
The test uses your current plan and storage allowance. It sends a temporary delivery, checks the returned original with SHA256 and revokes the delivery afterwards. It transfers your selected data to Elara storage and back. Keep this tab open.
Use a representative file you are authorised to transfer. Quick send supports up to 1 GB; account plans support 5 GB, 20 GB or 1 TB per delivery. The benchmark reads the download as a stream rather than collecting the whole returned file in memory.
Automatic keeps the current Send selection. Compare direct multipart with Gear using the same original above 32 MiB. The selected method is recorded with every attempt.
Controlled parallel upload comparison
Compare the same file with a fixed request limit. Automatic uses the current sender policy. Device capacity and the selected method can reduce actual parallelism.
Verify a complete original from real source data.
This test fetches a 64 MiB interval from a fixed public model file, sends it through the current Send browser client, then downloads and verifies the complete original in this browser. Allow approximately 192 MiB of data transfer before protocol overhead when the upload is uncompressed. Keep this tab open.
The source download and reference SHA256 check happen before timing. The measured time includes fresh source checking, upload, complete server readiness, recipient download, closing the saved file, an independent full reread and publication of the verified original in browser storage.
Requires browser storage with file rename support and your current Send allowance. The source and downloaded original remain in browser storage. The temporary delivery is revoked afterwards. Results stay on this page until you leave or refresh; download the JSON to retain up to 20 attempts, including failures.
A complete 793 MB original, saved and verified.
On 26 October 2026, a complete Debian installation image passed a fresh upload, storage verification and full recipient readback. The saved file was synchronised to disk and independently reread. Its SHA256 matched the official source.
| Milestone | Elapsed time | What finished |
|---|---|---|
| Upload receipt | 20.85 s | All 24 parts durably acknowledged. |
| Original ready | 41.54 s from the saved source | Complete storage verification, including the upload. |
| Recipient download and save | 107.55 s | Every returned byte hashed, then the receiver file synchronised and closed. |
| Complete journey | 163.75 s | Official source acquisition through an independent reread of the saved recipient file. |
Twelve simultaneous upload requests were observed. The run had zero retries, compression savings and reused bytes. This Linux Node sender and receiver shared one compute host. Readback used the authenticated proxy. One small direct download probe overlapped readback. This control establishes the stated original and route; browser performance, independent device performance, 1 TB capacity and competitor rankings require their own completed tests.
10 GB uploaded and read back in full.
A 10,000,000,000 byte capacity control passed the production upload, complete storage verification and full returned SHA256 check. Every raw byte was uploaded across 299 parts. Twelve simultaneous upload requests were observed with zero retries.
| Milestone | Elapsed time |
|---|---|
| Full source read and hash | 6.56 s |
| Upload and commit | 231.08 s |
| Additional storage verification | 159.67 s |
| Native readback and SHA256 | 315.62 s |
| Source checking through verified readback | 712.93 s |
The fixture repeats the verified Debian source to exactly 10 GB. Deduplication and compression were disabled; all 10 GB travelled through storage and back. A Linux Node client streamed the returned original without retaining a 10 GB recipient file. This is a raw capacity control, with sequential server verification. It does not qualify a browser journey, a saved 10 GB recipient, 1 TB delivery or a competitor ranking.
Parallel verification reduced waiting in this 10 GB control.
Download the production control summary
A second account sent the same 10 GB fixture through the existing direct original route with canonical source checkpoints. All 10 GB were uploaded, verified in 150 signed ranges and returned with the matching full SHA256. Sixteen simultaneous verification jobs were observed.
| Milestone | Sequential verification | Parallel verification |
|---|---|---|
| Source read and preparation | 6.56 | 31.02 |
| Upload and commit | 231.08 | 211.19 |
| Additional storage verification | 159.67 | 25.88 |
| Full source start through verified readback | 712.93 | 598.50 |
This is one API trial per route on one shared Linux host, using separate accounts and the same native ranged recipient path. Source preparation, upload, verification and every returned byte are included. An auxiliary source preparation trial overlapped the first verification, and coordinator evidence reads overlapped the second recipient readback. Neither trial saved a 10 GB recipient file. The observed difference is not a general speed guarantee, browser result, LRO compression result or matched competitor ranking. Parallel verification is currently selected through the explicit direct original option; automatic video transport can still use sequential verification.
Four senders completed together.
Four separate test accounts each sent and received a distinct 128 MiB interval of the verified real source. All four saved originals passed an independent disk SHA256 check. Completion took 24.33 to 28.81 seconds per sender, with zero retries and 536,870,912 bytes uploaded and returned in total.
The transfers began from a common barrier and shared one Linux compute host. Recipient reads used the normal direct storage route. This establishes four overlapping account deliveries on that path. It does not establish browser concurrency, independent device performance or capacity for a larger user population.
Real 4K media validation.
A complete 673,223,862 byte video passed upload, server verification and complete recipient readback on 21 October 2026. All 81 parts were accepted, eight simultaneous direct R2 uploads were observed, and the returned SHA256 matched the original.
| Stage | Elapsed time | Measured rate |
|---|---|---|
| Upload receipt | 95.53 s | 56.38 Mbit/s |
| Server verification wait | 33.33 s | Separate from upload |
| Recipient download and SHA256 | 26.37 s | 204.25 Mbit/s |
Public Big Buck Bunny 2160p video. Linux Node client. This was a full original upload with no payload reuse or compression saving. Link capacity and endpoint location were not established. This trial is separate from the browser results below and does not establish a competitor ranking.
Recorded browser results.
Three fresh 64 MiB synthetic originals completed upload and verified readback on 18 October 2026. Each returned the exact source SHA256. Reuse contributed zero bytes and every original byte was uploaded. These historical upload rates end at the upload receipt and exclude the subsequent server verification wait. New tests report complete verified availability separately.
| Stage | Elapsed time | Measured rate |
|---|---|---|
| Historical upload receipt lifecycle | 15.88 s | 33.81 Mbit/s |
| Ranged download and SHA256 | 5.80 s | 92.58 Mbit/s |
Chrome 154 in a cloud browser. Network location and link rate were not established. Authenticated proxy with bounded range reads and incremental SHA256. These observations describe the tested path and conditions. They are not a matched competitor ranking.
The separate 500 MB validation
A 500,000,000 byte synthetic file reached verified storage through the browser. Its separately measured browser readback completed 30 ranges with two access grants, no retries and an independently matching SHA256. Readback, including authorisation and hashing, took 77.96 s. The preview interrupted the continuous upload benchmark, so no upload speed is assigned to that attempt.
What counts as a fair speed comparison?
Use the same source bytes and SHA256 manifest, device, browser, connection, locations and account tier. Run each service at least five times in varied order. Keep first uploads separate from reuse, warm caches and resumed uploads. Record every failure.
| Stage | Record | Why it matters |
|---|---|---|
| Preparation | Original bytes, encoded bytes, hashing and encoding time. | A smaller payload is distinct from a faster network. |
| Upload | First request to durable acceptance; upload lifecycle separately. | Browser progress alone does not prove storage or recipient readiness. |
| Availability | Time until an independent recipient can open the original. | Restoration and verification are part of the handover. |
| Download | Full original bytes received, elapsed time and SHA256. | A link opening is not a completed download. |
| Recovery | Disconnect, resume, bytes resent, completion and failures. | A huge estate has to finish reliably. |
Report medians and every attempt per test cell. Use at least five varied order trials for matched 1 GB, 10 GB, 100 GB and 1 TB files where each account permits them. Test several senders together, connection interruption and complete recipient recovery. A larger advertised limit is a capability claim, not a measured speed.
How to interpret existing observations
The reported observation of 500 MB in six seconds is approximately 667 Mbit/s using decimal MB. Its timing boundary, source, location, retries and readback evidence were not supplied here, so it is excluded from measured comparisons. The compression experiments on the Elara compression page establish results for those samples and engines; they do not establish this app’s transfer speed.
The browser test above exercises this app’s actual sending path. Elara prepares eligible files losslessly and reuses matching verified data when available, including parts of large files. Its sending phase timings include coordination and are not isolated wire throughput. An independent recipient, external packet counters and matched competitor runs remain separate tests.
Plan a huge data estate from the link upwards.
Estimate network time for a petabyte estate before scheduling a migration. Set the measured payload saving from a representative pilot. Zero is the starting assumption.
132.28 days before payload reduction.
132.28 days with your pilot saving.
Model only. Decimal PB and Gbit/s. Time equals payload bits divided by sustained bit rate. Excludes preparation, verification, disk limits, small object overhead, retries, outages, change capture and cutover. This calculation is not an Elara, R2 or competitor throughput guarantee.
Elara Send currently supports up to 1 TB per delivery on Studio and 200 files per delivery. A petabyte migration requires a scoped estate inventory, batch orchestration, measured recovery and destination acceptance. Discuss a managed migration pilot.