One of Tigris's standout capabilities is its performance when storing and retrieving small objects. To quantify this advantage, we benchmarked Tigris against two popular object stores—AWS S3 and Cloudflare R2—and found that Tigris consistently delivers higher throughput and lower latency. These gains let you use a single store for everything from tiny payloads to multi-gigabyte blobs without sacrificing efficiency.

If you're working in AI, you're probably working in Python. Maybe you have a webapp in whatever JS framework is popular right now, but most of the core tooling in AI is built in and around Python. So maybe it’s time for a Go programmer like me to figure out how the production Python gets made.

Last week I rediscovered Development Containers. When you use them, you do all your development in a container instead of on your machine directly. This container is defined using a devcontainer.json file and when you create a development container it’s rebuilt from scratch every time. This means that when you get your build working in development, it won’t just work on your machine. It’ll work on anyone’s machine.

Having to use Python shouldn't be that big of a deal, my first programming language was Python, but there’s one small problem that has resulted in me thinking that I have been cursed by an elder deity: Python environment management tools randomly break for me. I’ve never been able to figure out why this happens, but in the last three years I have not been able to consistently have basic editing, testing, or other project management tooling work reliably. I’ve spent hours debugging weird SIGBUS errors that nobody else can recreate and other things that go way above and beyond normal debugging of issues.

At Tigris we put your big data close to your compute so you don't have to do it yourself. However, there's been a small problem with that: most of the programs that are built to process that data such as AI training, document indexing, and other kinds of workloads expect to read data from a filesystem.

Not to mention, big data means big data. Bigger than ram. Bigger than your disk. Bigger than any one machine can have on any amount of disks. Sometimes even bigger than human minds can imagine. What if that data was as easy to access as your code folder, but had unlimited storage?

You’ve got your tunes in high gear, your editor is open, and you’re working on recreating some database tables with your AI agent in an epic duo. Your AI agent says “run this SQL query?” and you click yes. The tests pass, you make PR that’s quickly stamped and merged, when suddenly your pager goes off. And again. And again. You’ve just broken the analytics database and everything is on fire. What do you do?

There’s a new data lake on the market: DuckLake. It’s worth the hype because it gives you an open standard that not only enables you to run queries on your data lakes from anywhere, it outright encourages you to run your query, metadata, and storage layers separately in whatever platform works best for you. We've been thinking about DuckDB as a solution for Small Data, but now with the limitless storage capability of object storage, it can support massive scale datasets. Big Data doesn't have to be complicated.

One of the key changes with DuckLake is moving the metadata layer out of object storage and into a dedicated database. But why would an object storage company like Tigris be excited about putting less data in object storage?

Data migrations are risky. Data is sticky; once you put it somewhere, you need to spend a lot of time, energy, and egress fees trying to move it somewhere else. Let’s say you want to move all your data from The Big Cloud™ to another cloud. The gold standard process usually goes something like this:

By day I work on DevRel at Tigris Data, and by night I’m a virtual anime person that makes software deployed by the United Nations. A side project of mine took off recently, a Web AI Firewall Utility named Anubis. Anubis blocks abusive scrapers from taking out web services by asserting that clients that claim to act like browsers do, in fact, act like browsers. As usage has grown (yes, the UN actually uses Anubis), we’ve gotten creative about detecting bots, including setting honeypots that give us more detailed data on their requests. These honeypot logs are sent to Tigris, and we analyze them using DuckDB to find patterns and improve bot detection.

In this article I'm going to be calling those abusive scrapers "AI scrapers", but to be clear I'm not really sure if they are for training generative AI or not. However, the worst offender has been Amazon's Alexa team so it's pretty easy to take those two points and draw a line between them.

As usage of Tigris has grown, so has the need to protect it from abuse. Tigris is a globally distributed, multi-cloud object storage service with built-in S3 API support, and as more developers rely on it for performance and scale, we've also seen a natural increase in attempts to misuse the platform.

Earlier this year, a campaign dubbed "DeceptionAds" came to light, where attackers used fake CAPTCHAs hosted on trusted services to trick users into running malicious commands. The end result: installation of the Lumma info-stealer malware, which exfiltrates sensitive information like passwords and financial data. The attackers used a combination of Bunny CDN (a legitimate content delivery network) and BeMob (an ad tracking service) to distribute and cloak their payloads - demonstrating how malicious actors increasingly hide behind reputable infrastructure to evade detection.

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?