How Tigris Data Makes Object Storage Screaming Fast, Globally

Customer

Tigris Data

Founders

Ovais Tariq

Himank Chaudhary

Yevgeniy Firsov

For nearly 20 years, "object storage" meant Amazon S3. But S3's popularity turned its API into a standard. Now, startups are innovating with S3-compatible storage, integrating with AWS SDKs. Tigris Data capitalizes on this shift to deliver real-time performance to users everywhere from Sydney to São Paolo.

Forged in the Ride-Share Fires

It's a busy rush hour in Los Angeles. School is starting in Sydney. And the bars are closing in the Marais in Paris. People around the world are standing on rainy street corners, impatiently staring at their phones waiting for Uber to find them a ride.

That's the problem Ovais, Himank, and Yevgeny signed up for when they built out Uber's storage team: moving petabytes of data in real time across 600 cities and 50 data centers. It had to be synchronized, consistent, and reliable enough that drivers and riders never had to think it.

After almost a decade working on one of the toughest data engineering projects in the industry, object storage was an obvious next step. Enter Tigris Data.

The Most Important Problem in Storage

Object storage is the original cloud service, and, after the relational database, the industry's most important and widely-used storage technology. Bring up any app on your phone. Whatever you're looking at, much of it probably got pulled from an object store.

The reason is that the API is simple. An "object" is just a named blob of bytes. Objects are organized into "buckets". You can list a bucket, put an object into it, get it out, and eventually delete it. If you're a programmer, this a dream: those operations are all you need to know. A good object store handles all the rest of the details for you.

Hyperscaler Resiliency, Research Lab Speeds

Tigris builds object storage on top of FoundationDB. Widely regarded as one of the most reliable and scalable distributed database engines in the industry, FoundationDB is the engine behind storage industry megaprojects like Snowflake and Apple iCloud.

What most attracted Tigris to FoundationDB was its embrace of "simulation testing". The authors of FoundationDB literally built it first as a simulation, and that simulation is used with every new release to crank through massive amounts of automated reliability and constraint testing. Transoceanic cable cuts? Rogue backhoes? Data center fires? Whatever it is, bring it on. The FoundationDB test suite has seen worse. That's exactly what you want for a next-gen object store.

The challenge with classical object stores like S3 and Google Cloud Storage is performance. Hyperscalers are phenomenal at reliably scaling storage. But delivering that data back to users across the globe — in Sydney, London, and Dallas at the same time — is tricky, even for Amazon.

Here's where Tigris does things differently. Instead of asking developers to place buckets in specific locations around the world, Tigris buckets are global. An intelligent routing layer caches and replicates objects wherever users demand them. The system just figures out where data should live to make globally distributed apps fast.

AI-Model Scale With Near-Redis Performance

The typical "object" in S3 is an uploaded photo, making object stores the go-to for handling "files" and "documents" in apps — and Tigris excels at these workloads. But with global low-latency fetches, Tigris unlocks a bunch of new use cases.

Taking advantage of core FoundationDB features, Tigris "inlines" small objects in its metadata storage, storing object bytes right alongside routing information. For small objects, Tigris can achieve performance comparable to Redis, with full consistency and replicated storage. By extending the S3 API with compare-and-set, transactions, and SQL-style query logic over metadata, Tigris blurs the line between object stores and databases.

Tigris Does Things Even S3 Can't, and You Can Be Using It in Minutes

In several ways, Tigris Data exceeds S3. Tigris runs directly on top of Fly.io's infrastructure, redundantly storing data directly across our NVMe volumes as well as off-network object storage peered directly to Fly.io's networks. That means reaching a Tigris bucket from inside another app running on Fly.io often incurs nothing more than an Ethernet hop across a rack switch. A globally deployed app on Fly.io can do things with Tigris that are difficult to replicate on other public clouds.

You can use Tigris buckets to cost-effectively store hundreds of gigabytes of AI model weights, tiny individual chat messages, and anything in between. If your app works with S3, it works with Tigris, just by changing your object store URLs.

It's freaky easy to get started with, and you will never, ever outgrow it.