Small Objects, Big Gains: Benchmarking Tigris Against AWS S3 and Cloudflare R2
tigrisdata.comThis makes no sense. They ran the tests from a “neutral cloud provider”, as if someone is using AWS S3 to store their Azure and GCP data?? And they didn’t explain where exactly Tigris was running or how they controlled for the network latency. AWS is insanely faster when the compute is in the same region as the storage. They also didn’t mention what class of S3 they used or what replication settings (eg. S3 has express one zone).
I’m all for benchmarking and showing that your product is better from a technical standpoint. But at least for me, this is not the way.
Author of the blog post here.
The test is relevant for users running workloads across multiple clouds, or running in neo-clouds like Coreweave, Together.ai, Lambda Labs, etc. In such cases, the storage is typically S3, or R2.
There is of course going to be additional latency when S3 is used outside the AWS network. But that is the practical case as well when using S3 in multi-cloud workloads. The same applies to R2, which is often used outside their worker product through compute that is not part of the Cloudflare network infra.
The benchmark uses standard tier for buckets, which tends to be the most common. The blog post should have mentioned the tier. A miss from my side.
What more would you have wanted to see? The benchmark is using the open source go-ycsb tool and is easily reproducible.
The testing VM is specified as VM.Standard.A1.Flex (Oracle Cloud)
Is this the endpoint you tested against? https://bgp.he.net/dns/t3.storage.dev#_ipinfo
Did you test from a VM in the same cloud that's hosting the product? If so I'm not sure "neutral cloud provider" is an honest statement.
Agree. There are literally zero takeaways from this article other than it being a marketing post.
The takeaway is that if your workload involves small objects (which we see with training workloads for our customers), and you are using the neoclouds, then Tigris will offer better latency and throughput.