A Tigris Data co-founder explains how the globally distributed S3-compatible object store is built on FoundationDB for metadata, indices, and task queues. The talk covers why FoundationDB was chosen (ACID transactions, ordered keyspace, operational safety), how writes bundle metadata updates and queue tasks into a single atomic transaction, how reads are resolved across regions via caching and reverse-proxy fetches, and how a custom queueing system modeled on Apple's QuiCK paper drives global replication without a separate coordination system like Kafka.
Table of contents
What is Tigris? Read and write in any regions Why FoundationDB? FoundationDB at the core What do writes do? How do we resolve GETs? Our queueing system Conclusion Further reading Questions this post answers
How does Tigris avoid running a distributed transaction between a database and a message queue?
Tigris implements its own message queue directly inside FoundationDB, treating the queue as an ordered keyspace where workers claim rows transactionally. Because both the object metadata and the queue tasks live in the same FoundationDB transaction, either everything commits together or nothing does, eliminating the need for a separate two-phase commit across a database and a queue like Kafka. Teams weighing FoundationDB against a database-plus-queue setup can track real-world architecture writeups like this on daily.dev.
How does a global object store serve a GET request when the object isn't stored in the local region?
Tigris reverse proxies the read to the block store in the region where the data actually lives, since metadata is eagerly replicated across FoundationDB clusters in every region and always records the object's true location. It then enqueues a background replication job so the object is copied into the local region, making subsequent GET requests faster. Developers designing multi-region caching and replication strategies can follow architecture deep dives like this on daily.dev.
Why did Tigris choose FoundationDB instead of building its own distributed transaction layer for object storage metadata?
FoundationDB provides ACID transactions, an ordered keyspace, and operational safety with extensive simulation testing, letting Tigris avoid building sharding, consensus, and replication from scratch. It is already battle-tested in production by companies like Apple and Snowflake, so Tigris only needed to build its own schema and indexing layer on top rather than the underlying distributed primitives. Engineers evaluating FoundationDB versus building custom storage internals can find comparisons like this on daily.dev.