[Blog](/blog/.md)

<!-- -->

/

<!-- -->

[Updates](/blog/tags/updates/.md)

# Small Objects, Big Gains: Benchmarking Tigris Against AWS S3 and Cloudflare R2

Ovais Tariq · July 8, 2025 ·

<!-- -->

8 min read

[![Ovais Tariq](https://github.com/ovaistariq.png)](https://www.linkedin.com/in/ovaistariq/)

[Ovais Tariq](https://www.linkedin.com/in/ovaistariq/)

Co-Founder @ Tigris Data

![Benchmark science](/blog/assets/images/benchmark-science-dd18ae65ed4f946fd740c8cde81b97dc.webp)

One of Tigris's standout capabilities is its performance when storing and retrieving small objects. To quantify this advantage, we benchmarked Tigris against two popular object stores—AWS S3 and Cloudflare R2—and found that Tigris consistently delivers higher throughput and lower latency. These gains let you use a single store for everything from tiny payloads to multi-gigabyte blobs without sacrificing efficiency.

<!-- -->

Under the hood, Tigris accelerates small-object workloads by (i) inlining very small objects inside metadata records, (ii) coalescing adjacent keys to reduce storage overhead, and (iii) caching hot items in an on-disk, LSM-backed cache.

## Summary[​](#summary "Direct link to Summary")

Our benchmarks reveal that Tigris significantly outperforms both AWS S3 and Cloudflare R2 for small object workloads. Our benchmarks show Tigris achieves **sub-10ms** read latency and **sub-20ms** write latency, while sustaining **4 x throughput** than S3 and **20 x throughput** than R2 for both operations.

To ensure our findings are reproducible, we outline the full benchmarking methodology and provide links to all artifacts.

Object Storage That's Faster Than S3 and R2

Tigris is 5.3x faster than S3 and 86.6x faster than R2 for small object reads. If your workload depends on reading lots of small objects—logs, AI features, or billions of tiny files—this matters.

[Check Out the Docs!](https://www.tigrisdata.com/docs/get-started/)

## Benchmark Setup[​](#benchmark-setup "Direct link to Benchmark Setup")

We used the [Yahoo Cloud Serving Benchmark (YCSB)](https://en.wikipedia.org/wiki/YCSB) to evaluate the three systems. We [added support](https://github.com/pingcap/go-ycsb/pull/307) for S3-compatible object storage systems (such as Tigris and Cloudflare R2), which was merged shortly after publish.

All experiments ran on a neutral cloud provider to avoid vendor-specific optimizations. Table 1 summarizes the test instance:

*Table 1: Benchmark host configuration.*

| Component         | Quantity                           |
| ----------------- | ---------------------------------- |
| Instance type     | VM.Standard.A1.Flex (Oracle Cloud) |
| Region            | us-sanjose-1 (West Coast)          |
| vCPU cores        | 32                                 |
| Memory            | 32 GiB                             |
| Network bandwidth | 32 Gbps                            |

### YCSB Configuration[​](#ycsb-configuration "Direct link to YCSB Configuration")

We benchmarked a dataset of 10 million objects, each 1 KB in size. You can view our configuration in the [tigrisdata-community/ycsb-benchmarks](https://github.com/tigrisdata-community/ycsb-benchmarks) GitHub repo, specifically at [results/10m-1kb/workloads3](https://github.com/tigrisdata-community/ycsb-benchmarks/blob/main/results/10m-1kb/workloads3).

Our buckets were placed in the following regions per provider:

| Provider      | Region                                                               |
| ------------- | -------------------------------------------------------------------- |
| Tigris        | `auto` (globally replicated, but operating against the `sjc` region) |
| AWS S3        | `us-west-1` (Northern California)                                    |
| Cloudflare R2 | `WNAM` (Western North America)                                       |

## Results[​](#results "Direct link to Results")

Using YCSB we evaluated two distinct phases: (i) a bulk load of 10 million 1 KB objects and (ii) a mixed workload of one million operations composed of 80% reads and 20% writes.

### Loading 10 million objects[​](#loading-10-million-objects "Direct link to Loading 10 million objects")

Figure 1 (below) plots the end-to-end ingestion time. Tigris finishes the load in **6711 s**, which is roughly **31 % faster than S3 (8826 s)** and **an order of magnitude faster than R2 (72063 s)**.

Latency drives this gap. As shown in Figure 2, R2's p90 PUT latency tops **340 ms** whereas Tigris stays below **36 ms** and S3 below **38 ms**. Table 2 summarises the key statistics.

*Table 2: Load-phase latency and throughput metrics.*

| Service | P50 Latency (ms)                                         | P90 Latency (ms)                                        | Runtime (sec)                                           | Throughput (ops/sec)                                       |
| ------- | -------------------------------------------------------- | ------------------------------------------------------- | ------------------------------------------------------- | ---------------------------------------------------------- |
| Tigris  | 16.799<!-- --><!-- -->ms                                 | 35.871<!-- --><!-- -->ms                                | 6710.7<!-- --><!-- -->sec                               | 1490.2<!-- --><!-- -->ops/sec                              |
| S3      | 25.743<!-- --><!-- -->ms(<!-- -->1.53<!-- -->x Tigris)   | 37.791<!-- --><!-- -->ms(<!-- -->1.05<!-- -->x Tigris)  | 8826.4<!-- --><!-- -->sec(<!-- -->1.32<!-- -->x Tigris) | 1133<!-- --><!-- -->ops/sec(<!-- -->0.76<!-- -->x Tigris)  |
| R2      | 197.119<!-- --><!-- -->ms(<!-- -->11.73<!-- -->x Tigris) | 340.223<!-- --><!-- -->ms(<!-- -->9.48<!-- -->x Tigris) | 72063<!-- --><!-- -->sec(<!-- -->10.74<!-- -->x Tigris) | 138.8<!-- --><!-- -->ops/sec(<!-- -->0.09<!-- -->x Tigris) |

![Figure 1 – Total load time – Tigris vs S3 vs R2](/blog/assets/images/total-time-load-comparison-c7c8a483cc6a0513151002e5975cef61.webp "Total load time – Tigris vs S3 vs R2")

*Figure 1: Total load time for loading 10 M 1 KB objects.*

R2 takes more than 300ms to write a single object which explains the slowness of the data load.

While comparing Tigris latency to S3, it is still better but not the same margin as compared to R2.

![Figure 2 – PUT p90 latency – Tigris vs S3](/blog/assets/images/load-sjc-s3-tigris-insert-latency_p90_ms-a8196adadd9cba9727d3adf362c0cefb.webp "PUT p90 latency – Tigris vs S3")

*Figure 2: PUT p90 latency during load phase.*

### 1 million operations (20% write, 80% read)[​](#1-million-operations-20-write-80-read "Direct link to 1 million operations (20% write, 80% read)")

This is the *run* phase of the YCSB benchmark. As a reminder, it is a 20% write and 80% read workload totaling 1 million operations.

#### Read throughput[​](#read-throughput "Direct link to Read throughput")

![Figure 3 – Read throughput – Tigris vs R2](/blog/assets/images/run-sjc-r2-tigris-read-throughput_ops-bb6db6d7c60d1e342d2087f301535376.webp "Read throughput – Tigris vs R2")

*Figure 3: Read throughput during mixed workload (Tigris vs R2).*

![Figure 4 – Read throughput – Tigris vs S3](/blog/assets/images/run-sjc-s3-tigris-read-throughput_ops-da1529d6996ffc426d42dd46b6811614.webp "Read throughput – Tigris vs S3")

*Figure 4: Read throughput during mixed workload (Tigris vs S3).*

Throughput traces for all three providers remain stable—useful for capacity planning—but the absolute rates diverge sharply. Tigris sustains **≈3.3 k ops/s**, nearly **4 × S3 (≈ 892 ops/s)** and **20 × R2 (≈ 170 ops/s)**. This headroom lets applications serve real-time workloads directly from Tigris.

#### Read latency[​](#read-latency "Direct link to Read latency")

![Figure 5 – Read p90 latency – Tigris vs R2](/blog/assets/images/run-sjc-r2-tigris-read-latency_p90_ms-46e643e2523ea34e05f440062383f8a1.webp "Read p90 latency – Tigris vs R2")

*Figure 5: Read p90 latency during mixed workload (Tigris vs R2).*

![Figure 6 – Read p90 latency – Tigris vs S3](/blog/assets/images/run-sjc-s3-tigris-read-latency_p90_ms-3000f66d81b1ae1c47e9b3b4a70d1b3c.webp "Read p90 latency – Tigris vs S3")

*Figure 6: Read p90 latency during mixed workload (Tigris vs S3).*

Latency follows the same pattern. Tigris keeps p90 below **8 ms**; S3 settles around **42 ms**, and R2 stretches beyond **199 ms**. At sub-10 ms, reads feel closer to a key-value store than a traditional object store.

#### Write throughput[​](#write-throughput "Direct link to Write throughput")

![Figure 7 – Write throughput – Tigris vs R2](/blog/assets/images/run-sjc-r2-tigris-update-throughput_ops-7b468a6c33651d711a76962ca6e53077.webp "Write throughput – Tigris vs R2")

*Figure 7: Write throughput during mixed workload (Tigris vs R2).*

![Figure 8 – Write throughput – Tigris vs S3](/blog/assets/images/run-sjc-s3-tigris-update-throughput_ops-2d86342ca555dc256bebefdce130d28e.webp "Write throughput – Tigris vs S3")

*Figure 8: Write throughput during mixed workload (Tigris vs S3).*

Write throughput shows the same spread. Tigris delivers **≈ 828 ops/s**, close to **4 × S3 (224 ops/s)** and **20 × R2 (43 ops/s)**, giving plenty of margin for bursty ingest pipelines.

#### Write latency[​](#write-latency "Direct link to Write latency")

![Figure 9 – Write p90 latency – Tigris vs R2](/blog/assets/images/run-sjc-r2-tigris-update-latency_p90_ms-b0ae5cb55a67e1338eff80caf30c04e0.webp "Write p90 latency – Tigris vs R2")

*Figure 9: Write p90 latency during mixed workload (Tigris vs R2).*

![Figure 10 – Write p90 latency – Tigris vs S3](/blog/assets/images/run-sjc-s3-tigris-update-latency_p90_ms-58050f54ed75eb2ced477ee5e81ceb4e.webp "Write p90 latency – Tigris vs S3")

*Figure 10: Write p90 latency during mixed workload (Tigris vs S3).*

Write-side tail latency tracks proportionally: **< 17 ms** for Tigris, **≈ 41 ms** for S3, and **> 680 ms** for R2—an order-of-magnitude gap that can make or break user-facing workloads.

To summarize:

*Table 3: Read and throughput metrics.*

| Service | P50 Latency (ms)                                          | P90 Latency (ms)                                         | Runtime (sec)                                            | Throughput (ops/sec)                                       |
| ------- | --------------------------------------------------------- | -------------------------------------------------------- | -------------------------------------------------------- | ---------------------------------------------------------- |
| Tigris  | 5.399<!-- --><!-- -->ms                                   | 7.867<!-- --><!-- -->ms                                  | 241.7<!-- --><!-- -->sec                                 | 3309.8<!-- --><!-- -->ops/sec                              |
| S3      | 22.415<!-- --><!-- -->ms(<!-- -->4.15<!-- -->x Tigris)    | 42.047<!-- --><!-- -->ms(<!-- -->5.34<!-- -->x Tigris)   | 896.8<!-- --><!-- -->sec(<!-- -->3.71<!-- -->x Tigris)   | 891.5<!-- --><!-- -->ops/sec(<!-- -->0.27<!-- -->x Tigris) |
| R2      | 605.695<!-- --><!-- -->ms(<!-- -->112.19<!-- -->x Tigris) | 680.959<!-- --><!-- -->ms(<!-- -->86.56<!-- -->x Tigris) | 4705.3<!-- --><!-- -->sec(<!-- -->19.47<!-- -->x Tigris) | 42.6<!-- --><!-- -->ops/sec(<!-- -->0.01<!-- -->x Tigris)  |

*Table 4: Update and throughput metrics.*

| Service | P50 Latency (ms)                                         | P90 Latency (ms)                                         | Runtime (sec)                                           | Throughput (ops/sec)                                       |
| ------- | -------------------------------------------------------- | -------------------------------------------------------- | ------------------------------------------------------- | ---------------------------------------------------------- |
| Tigris  | 12.855<!-- --><!-- -->ms                                 | 16.543<!-- --><!-- -->ms                                 | 241.6<!-- --><!-- -->sec                                | 828.1<!-- --><!-- -->ops/sec                               |
| S3      | 26.975<!-- --><!-- -->ms(<!-- -->2.1<!-- -->x Tigris)    | 41.215<!-- --><!-- -->ms(<!-- -->2.49<!-- -->x Tigris)   | 896.8<!-- --><!-- -->sec(<!-- -->3.7<!-- -->x Tigris)   | 223.6<!-- --><!-- -->ops/sec(<!-- -->0.27<!-- -->x Tigris) |
| R2      | 605.695<!-- --><!-- -->ms(<!-- -->47.12<!-- -->x Tigris) | 680.959<!-- --><!-- -->ms(<!-- -->41.16<!-- -->x Tigris) | 4705.3<!-- --><!-- -->sec(<!-- -->19.4<!-- -->x Tigris) | 42.6<!-- --><!-- -->ops/sec(<!-- -->0.05<!-- -->x Tigris)  |

## Conclusion[​](#conclusion "Direct link to Conclusion")

Tigris outperforms S3 and comprehensively outperforms R2 for small object workloads. The performance advantage stems from Tigris's optimized architecture for small objects. While S3 and R2 struggle with high latency on small payloads (R2's p90 PUT latency reaches 340ms), Tigris maintains consistent low latency through intelligent object inlining, key coalescing, and LSM-backed caching.

These results demonstrate that Tigris can serve as a unified storage solution for mixed workloads, eliminating the need to maintain separate systems for small and large objects. Whether you're storing billions of tiny metadata files or streaming gigabytes of video data, Tigris delivers optimal performance across the entire object size spectrum.

You can find the full benchmark results in the [ycsb-benchmarks](https://github.com/tigrisdata-community/ycsb-benchmarks) repository.

**Tags:**

* [Updates](/blog/tags/updates/.md)
* [benchmarks](/blog/tags/benchmarks/.md)