Tigris is a globally distributed S3-compatible object storage solution available that can easily be hosted on Fly.io. In this article, we'll explore how Tigris fits into the existing slate of object storage options and why you might choose one over the other.

You don't need a CDN​

Probably the most exciting aspect of Tigris is its globally distributed nature. But what does that actually mean?

First, consider a common setup: you want to quickly deliver assets to users from your object storage, so typically you’d need to make use of a content delivery network (CDN) to cache your data in multiple regions, which helps reduce latency. When using Amazon S3, Cloudfront is the CDN most often used.

With Tigris, you don’t need a CDN at all because your data is available in all regions from the start. Global distribution means that the same bucket can store data in many different locations. You can effectively have a CDN-like system for delivering data to any region in a matter of minutes. Unlike a CDN, updates to data can occur in any region, allowing users in that region to see changes faster.

Streamlined developer experience​

Getting started with Tigris is as simple as running a single command to create a bucket:

fly storage create

When run in the directory of a deployed Fly App, it will create a new private Tigris bucket and set the following secrets on your app:

BUCKET_NAME
AWS_ENDPOINT_URL_S3
AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY

If you were already using the S3 API in your app, there's no need to change your code aside from updating the values of your environment variables/secrets.

Streamlined authorization​

Tigris buckets are private by default but can be made public to allow anyone to read their content. Additionally, Tigris supports Role-Based-Access-Control (RBAC), with a few predefined roles: Admin, Editor, and ReadOnly. A complete list of the permitted operations for each of these roles can be found here. You can use the predefined roles mentioned above, or you can define your own roles using custom IAM policies.

Migrating is easy (without being locked in)​

Migrating is made easier by the use of shadow buckets. Tigris shadow buckets allow you to incrementally migrate the data from an existing S3 or a compatible bucket without incurring egress costs or downtime. And if you migrate, you won't be locked in – Tigris doesn't charge for egress. 😀 💸

Conclusion​

Tigris is revolutionizing object storage for global apps. For developers seeking an efficient, scalable storage solution without the burden of extra costs or technical overhead, Tigris offers a compelling alternative. Give it a try today on your next app on Fly.io!

Eighteen years ago today, Amazon completely changed how developers work with data storage by giving us Simple Storage Service (S3).

S3 rewrote the rules of storage and propelled us into a new era of cloud computing. Traditional storage solutions were cumbersome and costly, and they shackled developers to the limitations of the hardware. With S3, Amazon introduced a shift towards Storage as a Service, liberating developers from the burdensome tasks of purchasing, provisioning, and managing physical storage. No longer were they bound by the precarious dance of capacity planning, where overestimating meant wasted resources and underestimating spelled disaster for uptime.

Hello, world! We're Tigris Data, and today we're announcing the public beta of Tigris. Tigris is a globally distributed object storage service that provides low latency anywhere in the world, enabling developers like you to store and access any amount of data using the S3 libraries you're already using in production. Today, we're launching our public beta on top of Fly.io.

Tigris is a globally available, S3 compatible object storage service.

Tigris uses FoundationDB's transactional key-value interface as its underlying storage engine. In our blog post Skipping the boring parts of building a database using FoundationDB we went into the details of why we chose to build on FoundationDB. To recap, FoundationDB is an ordered, transactional, key-value store with native support for multi-key strictly serializable transactions across its entire keyspace. We leverage FoundationDB to handle the hard problems of durability, replication, sharding, transaction isolation, and load balancing so we can focus on higher-level concerns.

We are starting a series of blog posts that go into the details of how Tigris has been implemented. In the first post of the series, we will share the details of how we have built the metadata storage layer on top of FoundationDB. We will cover the topics of data layout, and schema management.

Tigris being S3 compatible, offers S3-supported authentication and authorization methods. AWS S3 evolved in offerings for their authentication and authorization needs. We support what AWS S3 recommends to their users as of now for the AuthN and AuthZ needs.

I did a presentation at the FoundationDB Monthly Meetup. The talk is about, how building secondary indexes for a database is always about balance. A balance between a system that scales and is easy to manage and an API that is intuitive and delightful for a developer to use. Recently at Tigris Data, we have been adding secondary indexes to our metadata store and have been working hard to achieve a good balance between scale and developer delight. Tigris is a storage platform that leverages FoundationDB as one of its core components. In this talk I cover four aspects we had to balance:

1. Handling schema changes automatically in our secondary indexes.
2. The trade-off between auto-indexing all fields and indexing select fields.
3. Changes we made after performance testing.
4. How we plan build indexes in the background with minimal conflicts.

Client-side encryption refers to the practice of encrypting data on the client side (user's device) before it is transmitted to a server or stored in a remote location. This approach enhances the security and privacy of user data by ensuring that sensitive information is encrypted locally, and only the encrypted form is transferred or stored on the server.

Here's how client-side encryption typically works:

We are running FoundationDB with the official kubernetes operator. FoundationDB supports logical backups (with backup_agent) and disaster recovery (with dr_agent) through copying the database/streaming changes logically. It also supports binary backups through disk snapshots.

In this blog post, we will describe how to make a backup of FoundationDB via backup_agent. The FoundationDB operator supports making logical backups via backup_agent, but it does not support running DR with dr_agent. We decided to run backup_agent as a separate deployment to allow a symmetric setup with dr_agent.

In computer systems, username and password has become a widely used way to authenticate users. The evolution of password storage and authentication methods has gone through various stages to enhance security and protect user credentials.

Tigris is a globally available, S3 compatible object storage service. Tigris utilizes FoundationDB's transactional key-value interface for its underlying metadata storage. This blog delves into the topics of serializable transactions, the mechanics of transactions within Tigris, and concurrency control.