S3 changed the economics and ergonomics of object storage so completely that "S3-compatible" became a de facto standard interface for an entire category of storage products. The API contract that AWS defined in the early years of object storage has become the thing that storage infrastructure has to be compatible with, regardless of who provides it. That's a remarkable outcome for a single product's design decisions.
The S3 model makes a specific set of tradeoffs that were appropriate for its era. Storage is centralized in a region. Objects have a canonical location. Reads from outside the region incur network latency. Data egress costs are charged when data moves across region boundaries. For applications serving users primarily in one geography, these tradeoffs are acceptable. For applications serving users globally, or for applications running on distributed edge infrastructure, these tradeoffs create serious friction.
The data locality problem
The problem that Tigris addresses is structural and predictable: as compute moves toward the edge, storage has not kept pace. Edge compute platforms let you run function execution in dozens of locations globally, with automatic routing that places execution close to the user. The compute latency problem is largely solved. The storage latency problem is not.
An application running on edge compute that reads from a centralized S3 bucket has to round-trip from the edge node to the origin region for every storage read. This can mean adding 150-300ms to operations that the edge compute was meant to make sub-100ms. The edge compute investment is partially wasted if the storage access pattern requires returning to the origin.
Data residency regulations compound this. Increasingly, certain categories of user data must be stored in specific geographies — the jurisdiction where the user is located, or where the service is incorporated. An S3-compatible storage product that understands data locality at the object level, and can enforce storage placement based on the object's associated geography, addresses a regulatory requirement that is only going to become more stringent as data sovereignty regulation matures globally.
What the architecture does differently
The core architectural insight behind edge-first object storage is that data placement should be a property of the data, not a static configuration of the bucket. In a traditional object storage model, you create a bucket in a region and all objects in that bucket live in that region. The bucket is the unit of placement.
In an edge-first model, placement is dynamic. Objects are stored close to where they are accessed. A user in Southeast Asia reading an object reads it from a Southeast Asian PoP; the same object read by a user in Western Europe is served from a European location. The storage system handles replication and consistency across locations as a first-class concern rather than a bolt-on feature.
This is architecturally harder than it sounds. The consistency semantics of a globally distributed object store are genuinely complex. Different access patterns have different consistency requirements — a user profile object and a media file have different consistency needs. A well-designed globally distributed storage system needs to handle these differences with appropriate tradeoffs for each.
The investment logic
The bet on Tigris is a bet on the trajectory of the edge compute ecosystem. If edge compute adoption continues — and the architectural incentives strongly favor it for latency-sensitive applications — then the pressure to solve storage at the edge will increase. The applications that are currently running on centralized infrastructure will migrate toward edge infrastructure as the tooling matures. When they do, they will need storage that matches the distribution model of their compute.
The S3-compatible API is important here. Teams don't have to rewrite their storage integration to adopt Tigris. The existing integration patterns work. The migration path is a configuration change, not a codebase rewrite. That dramatically lowers the adoption barrier compared to a hypothetical edge storage product that required a new API.
The combination — familiar API, fundamentally different placement model, built-in data locality enforcement — is a compelling reason to believe the edge storage category is real and that Tigris is well-positioned within it.
Akave Capital is an investor in Tigris Data. This note reflects our investment thesis at the time of investment.