Storage Snapshot / Fork
Snapshot creation and fork latency across object storage providers — how fast can a provider branch your bucket?
Performance Over Time
Composite Score
Detailed Metrics
Provider | Score | Snapshot (med) | Fork (snap) (med) | Fork (live) (med) | First Read (med) | Success |
|---|---|---|---|---|---|---|
| Tensorlake | 99.8 | 0.03s | 0.22s | 0.25s | 0.09s | 100% |
| Tigris | 99.6 | 0.11s | 0.29s | 0.36s | 0.29s | 100% |
| Azure Blob | 97.1 | 1.68s | 1.69s | 3.30s | 0.03s | 100% |
| Archil | 0.0 | 0.00s | 0.00s | 0.00s | 0.00s | 0% |
| AWS S3 | 0.0 | 0.00s | 0.00s | 0.00s | 0.00s | 0% |
| Cloudflare R2 | 0.0 | 0.00s | 0.00s | 0.00s | 0.00s | 0% |
| Mosaic | 0.0 | 0.00s | 0.00s | 0.00s | 0.00s | 0% |
| Neon | 0.0 | 0.00s | 0.00s | 0.00s | 0.00s | 0% |
Want to see a provider added?
Methodology
What We Measure
Each iteration seeds a small dataset (10 objects × 1 MB = 10 MB) into the provider bucket, then times four operations: snapshot create, fork from snapshot, fork from live, and a first object read from the fork to confirm time-to-usable.
Every created resource (objects, snapshot, forks) is torn down in a finally block so a failure mid-iteration does not leak storage or siblings.
Each provider runs 100 iterations per benchmark run. Benchmarks run weekly via GitHub Actions and results are committed to the public benchmarks repo.
How We Score
The Composite Score (0–100, higher is better) scores each latency metric against a 60-second ceiling: 100 × (1 − value / 60,000ms), weighted as follows, then multiplied by success rate.
- • Snapshot create median: 40%
- • Fork (from snapshot) median: 35%
- • Fork (from live) median: 15%
- • First read median: 10%
Providers with native zero-copy semantics (e.g. Tigris) create snapshots and forks in near-constant time. Copy-based emulation (S3, R2, Azure) scales with object count and total bytes, which becomes visible at larger dataset sizes.