Tigris makes your storage multicloud for you, so you don’t have to worry about all that.

Lifecycle rules automatically move your objects to archive or infrequent access tiers to help cut storage costs. This feature has become pretty standard for object storage systems, but under the hood, it’s relatively complex to implement. Especially when you’re building with global storage across many regions. Let’s walk through how we built the feature, and where things got a little complicated.

“Do this and then do that” is hard. Models need specific, stepwise instructions to perform tasks, and even then, they aren’t reliable about completing each step in the desired order. When we built the Tigris Model Context Protocol (MCP) Server we intentionally kept it minimal and composable. We focused only on creating and managing storage. But in thinking through developer experience, we found many of the workflows we wanted to build have multiple steps. Seems easy enough, but there’s a problem: models are missing the entire concept of chaining tools together to accomplish multi-step tasks.

We’ve built a new tool that does two things in sequence: it uploads an object and then creates a shareable URL for it. This should help you use Tigris for your apps that require sharing files with your friends. The URLs this tool generates will expire in 24 hours or however long you ask. But why is it a separate tool in the first place?

AI is all the rage these days, huh? The main problem comes when you're trying to use it in anger to get Real World Apps™️. One of the most popular usecases for AI has you take your documents, shove it all into a search engine, and then go from there to have your model generate responses rooted in the docs.

There's only one problem: every one of those examples leaves the details as an excercise for the reader. Not today! Today I'm going to show you how to ingest and search documents with LanceDB and Tigris.

On Tigris, you can set any domain name to point to any bucket. Why does this matter?

Multi-cloud is all the rage these days. A new neocloud pops up every week offering cheap compute, and running your apps on Kubernetes means they’re easily ported to another provider. Compute is fungible, but storage is sticky. Using a custom domain to front your bucket of data makes it easy to swap out storage providers without updating all the code that uses that storage.

We’ve made it easy to share buckets with your team. Surprisingly, it isn’t so easy to share buckets on $BigCloud. Life doesn’t have to be hard when you have good developer experience.

Let’s say you want to share a bucket in a big public cloud. Suddenly you need permissions to author IAM policies, and you have to worry about user policies, bucket policies, and trawl through the documentation to remember which verb means “this user can do this policy on these resources”. Tigris supports all the IAM goop you’re used to if you want to copy and paste something you already have. But you don’t have to deal with IAM policies if you don’t want to. We’ve made it easy to share access to buckets in the UI, exactly how you’d expect it to work.

As the saying goes, there’s two hard problems in computer science:

1. Cache invalidation
2. Naming things
3. Off-by-one errors

Tigris takes care of cache invalidation, and we’d love to help with that last one, but now we can help you out if you named your object wrong. That’s right, we’ve added the ability to rename objects.

Let’s say you’re trying to work on a clone of Twitter to learn how something like that is made with Next.js. Sooner or later, you’re gonna hit a wall: someone wants to change their avatar. It's vibe coding time!

I want you to imagine what life was like before we had object storage. Uploading files was a custom process. If you wanted to scale, you ended up having to hire storage area network experts that built complicated systems with terms like “LUN” and “erasure coding”. Your application had to either shell out to an FTP server to handle uploads or put them alongside the source code. Above all though: everything had to be planned in advance. You had to do capacity planning so that you could know how much storage you needed to buy and when you needed to buy it. You couldn’t just insert a credit card and then get all the storage you wanted.

In 2006, Amazon invented the concept of object storage, fundamentally changing how applications work. Storage became a faucet. If you want more, you simply turn the knob. Bottomless storage was revolutionary, and now we’ve come to expect storage to be decoupled from physical hardware. S3 paved the way for seamless data management across any environment as long as it had a connection back to Amazon.

One of the great things about modern AI editor workflows is how it makes it easier to get started. Normally when you open a text editor, you have an empty canvas and don’t know where to start. AI tools let you describe what you want and help you get started doing it.

“We’ve all been excited about AI editors making development fast and just plain fun.”

• Most developers, probably

Today we’re happy to announce that we’re making it even easier to get started with Tigris in your AI editor workflow. If you want to get to the part where you can plug configs into your AI editor and get started, head to Getting Started and get off to vibe coding your next generation B2B SaaS as a service.

At Tigris, globally replicated object storage is our thing. But why should you want your objects “globally replicated”? Today I’m gonna peel back the curtain and show you how Tigris keeps your objects exactly where you need them, when you need them, by default.

Global replication matters because computers are ephemeral and there’s a tradeoff between performance and reliability. But does there have to be?