We’re Tigris, a globally distributed object storage platform built for high-performance workloads. It’s designed to work seamlessly across clouds, countries, and continents, making it simple and efficient for developers. Try it out, you’ll be up and running in a minute.

Twitter has been lit (well, not exactly lit, but let’s say there is a lot of enthusiasm) with posts about the recent announcement by AWS about support for Conditional Writes in S3. So I thought I would write something about it as well.

It’s all about concurrency and races.​

Introduction​

I admit it. My first Tigris blog post about Eager and Lazy caching was kind of basic. It was important to cover the ground-work. The CDN aspect is important and I do like the summon-your-data pre-fetch header a lot. Now we get to the significantly more disruptive stuff. The things that while Tigris is an S3-compatible API it also provides features that enable entirely new use-cases and push the boundaries of what you can do with object storage. Let's see if we can't set your internal constraint-solver aflame with possibilities.

If you've been toying around in the AI space over the past few months, you've probably heard of Ollama. Ollama is a tool for running various LLMs locally on your own hardware, and currently supports a bunch of open models from Google, Facebook and independent sources.

Besides the basic terminal chat function, Ollama has an API for use from within your favourite programming languages. This means you can build your very own LLM-powered apps!

Let's say we've built the next killer LLM app: ChatWich (which allows you to chat with your sandwich) and people are loving it when you show it off on your laptop, but personally visiting all your customers with your computer in hand is getting tiring, and the travel bills are starting to outweigh the (awesome) frequent flyer miles you're getting.

It's time to move to the cloud.

At Tigris we offer a number of novel and practical improvements beyond what your typical Object Storage does. We fit these within the existing common APIs or as graceful extensions when necessary. In this post we look at how you can take control of the Tigris caching mechanism if you feel the need.

Since we launched our public beta three months ago, our usage has skyrocketed, and hundreds of early adopters have picked Tigris as their storage solution. We've implemented tons of requested features and invested heavily in Tigris' performance, security, and reliability. We're grateful for your feedback and confident that we are on track to make the most developer-friendly object storage service.

With that, we will start billing for Tigris usage in July because we're confident that Tigris is reliable enough for us to justify doing that. Check out our pricing page for details on the pricing structure. The beta tag will stay, but we'll offer the same support expected from a highly reliable production-ready platform. Check out our SLA page for details about our uptime commitment.

Generative AI is a fantastic tool to use to quickly create images based on prompts.

One of the issues with some of these platforms is that they don’t actually store the images in a way that makes them easier to retrieve after they’ve been created. Oftentimes you have to make sure to save it immediately after the process is completed, otherwise, it's gone. Luckily, Stability offers an API that can be used to programmatically generate images, and Tigris is the perfect solution to store those images for retrieval.

In this article, you’ll learn how to deploy an app to Fly.io that will allow you to generate images using the Stability API and automatically store them in a Tigris bucket.

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.

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.