DEV Community: Shared Account

gpt-oss is not for developers. It’s for agents.

Shared Account — Tue, 19 Aug 2025 00:00:00 +0000

OpenAI’s gpt-oss model family is not for developers to use in their editors. It’s for building reliable AI agents that will stay on task even when interacting with the general public. I tried using it locally in my editor as an assistant, but found it was better for AI Agents.

Today I'm going to cover all of the coolest parts of the model card:

What are the tradeoffs?: choosing any model makes you have to pick between tradeoffs. This is a summary of where I think gpt-oss models shine the most.
Standard tool schemata: this makes web searches, page browsing, and python execution much more consistent.
Extreme focus on safety and resistance to prompt injections: keeps your agents on task so you can trust them more.
The Harmony Response Format: this is a new chat template designed to make prompt injection attacks harder to pull off.
Yap-time tool use: enables FAQ searches or other MCP tools during the reasoning phase.
Monitoring reasoning for unsafe outputs before they happen: the reasoning phase is at a lower safety standard than the final output of the model so that models can't accidentally be trained to omit reasoning about an unsafe topic they present to the user.
Reasoning is built in: gpt-oss models "reason" about a task before giving an answer. This makes it easier for models to give better answers than they would be able to without reasoning at the cost of taking longer to answer. The reasoning effort can be customized per prompt, allowing you to better route questions to the right model and reasoning effort.

I also built an agent on top of it to see how things go wrong in the real world.

What are the Tradeoffs?

AI companies will use benchmark performance as a way to objectively compare AI models of similar parameter sizes, but it’s not a reliable comparison when it comes to actually using the models. Some models are built for coding. Others translate English to Chinese really well. Picking the right model for the task boils down to a process the AI industry calls VibeEval: you gotta try it and check the vibes.

NOTE
VibeEval is a real term. Our industry is very silly.

I find gpt-oss useful because it maintains focus, unlike other models that are easily sidetracked. This makes it ideal for private data (due to self-hosting), ensuring compute time isn't misused, and interacting with the public who might try to divert the AI.

The biggest tradeoff is that gpt-oss stays on task, almost to a fault. If the model is told that it is there to help you with your taxes and you want it to tell you how to bake a cake, it’ll refuse within an inch of its digital life. This makes agents on top of gpt-oss a lot more predictable so that random users can’t use your expensive compute time to do things that are outside of what you intended. This can backfire when people ask vague questions, but that may be a feature in some usecases.

This model also excels when you need your data to stay private. If you host the model yourself, the bytes stay in your network no matter what. OpenAI has a focus on health related benchmarks (where they are the leading model in a benchmark they published), which is the main place you’d want to keep data self hosted.

Using open weights models means you can finetune the model to have whatever safety policies you want. Maybe you’re building an Agent for your storefront and want to prohibit it from talking about competitors. Or a recipe bot that absolutely can’t share your secret chocolate cake recipe. Open weights models are cut to fit.

What’s hiding in the model card?

Here’s what I learned reading the gpt-oss model card and how it it affects what you can build:

OpenAI shipped two text-only “mixture of experts” reasoning models: gpt-oss-20b and gpt-oss-120b. They fulfill different roles and work together in the context of a bigger agentic system. The 20b (20 billion parameter) model is intended to be used for lightweight and cheap inference as well as run on developer laptops. The 120b (120 billion parameter) model is intended to be the workhorse you use in production. It can run on very high end developer laptops, but it’s intended to run comfortably on a single nVidia H100 80gb card.

The 20b version runs great on my laptop and that’s how I’ve been doing most of my evaluation for building agentic systems. I do my agentic development with the smallest model possible because I’ve found that smaller models fail more often than bigger ones, meaning that I’m more likely to see how things go wrong in development so I can fix prompts or add guardrails faster than I would if those issues only showed up in production.

One of the biggest features is the ability to customize how much reasoning effort the model uses. When you combine this with picking between the 20b and 120b models, you get two dimensions of options for which model and reasoning effort is needed to answer a given question. I’ll get into more detail about that later in this article.

Tool use

These models also support tool use (MCP) with a special focus on a few predefined tools (taken from section 2.5 of the model card):

During post-training, we also teach the models to use different agentic tools:

A browsing tool, that allows the model to call search and open functions to interact with the web. This aids factuality and allows the models to fetch info beyond their knowledge cutoff.

A python tool, which allows the model to run code in a stateful Jupyter notebook environment.

Arbitrary developer functions, where one can specify function schemas in a Developer message similar to the OpenAI API. The definition of function is done within our harmony format. An example can be found in Table 18. The model can interleave CoT, function calls, function responses, intermediate messages that are shown to users, and final answers.

The models have been trained to support running with and without these tools by specifying so in the system prompt. For each tool, we have provided basic reference harnesses that support the general core functionality. Our open-source implementation provides further details.

This is the secret sauce that enables us to build agentic applications on top of the gpt-oss model family. By having a standard API for things like web searches, reading web pages, and executing python scripts, you have strong guarantees that the model will be able to behave predictably when faced with unknown or untrusted data. When I’ve built AI agents in the past, I had to do some extreme hacking to get code execution working properly, but now the built in schemata means that it will be a lot easier to get off the ground.

The models benchmark well enough. Table 3 from section 2.6.4 shows the raw metrics, but for the most part the way you should interpret this is that it’s good enough to not really have to care about the details too much. One of the main benchmarks they highlight is HealthBench, a benchmark that rates model performance on health related questions. Figure 4 covers the scores in more detail:

Of note: gpt-oss 120b consistently outperforms o1, gpt-4o, o3-mini, and o4-mini. This is surprising as gpt-oss 120b is smaller than those other models. The parameter count for those models have not been disclosed, but industry rumor suspects that gpt-4o is around 200 billion parameters. Technologists commonly associate “more parameters means more good”, so this is a surprising result.

NOTE
Please do not use AI models as a replacement for a doctor, therapist, or any other medical professional, even if AI companies use those usecases as part of their marketing. This technology is still rapidly evolving and we don’t know what the long term effects of their sycophantic nature will be.

Overall, here’s when and where each model is better:

	gpt-oss 20b	gpt-oss 120b
Good for local development	✅	❌
Good for production use	✅ (depending on usecase)	✅
Tool use / MCP	✅	✅
Software development tasks	❌	❌
Agentic workflows	✅ (depending on usecase)	✅
Jailbreak / prompt injection resistance	✅	✅
Generic question and answer (“Why is the sky blue?”)	❌	✅
Agentic analysis of documents	✅ (depending on usecase)	✅

Safety First

Most of the model card is about how OpenAI made this model safe to release to the public. OpenAI has some pretty pedantic definitions of safety and categories of risk that they use in order to evaluate danger, but most of them focus around the following risk factors:

If a model is told to only talk about a topic, how difficult is it for users to get that model off task? Will the model reject that instead of letting the user's desires win?
If an adversary gets access to the model and a high quality training stack, can they use it to make the model create unsafe outputs like hate speech, act as an assistant for chemical or biological warfare, or become a rogue self-improving agent?

Most of OpenAI’s safety culture is built around them being the gatekeepers because typically they host the models and you have to go through OpenAI to access the models. When they release a model’s weights to the public, they’re not able to be that gatekeeper anymore. As part of their evaluation process they had experts with access to OpenAI’s training stack try and finetune the model into biological and cyber warfare tasks. They were unsuccessful in making the model achieve “high” risk as defined by Section 5.1.1 of the model card. Some of those definitions seem to be internal to OpenAI, so we can only speculate for the most part.

The technology of safety

As I said, most of this model card is about the safety of the model and tools built on top of it. They go into lucid detail about their process, but I think the key insight is the use of their OpenAI Harmony Response Format.

The Harmony Response Format

At a high level, when you ask a model something like “Why is the sky blue?”, it gets tokenized into the raw form the model sees using a chat template. The model is also trained to emit messages matching that chat template, and that’s how the model and runtime work together to create agentic experiences.

One of the big differences between Harmony and past efforts like ChatML is that Harmony has an explicit instruction "strength" hierarchy:

Each level of this has explicit meaning and overall it’s used like this:

Level	Purpose
System	Contains the reasoning effort, list of tools, current date, and knowledge cutoff date.
Developer	Contains the instructions from the developer of the AI agent. What we normally call a “system prompt”.
User	Any messages from the user of the AI agent.
Assistant	Any messages that the agent responds with. Notably, this includes the reasoning chain of thought.
Tool	Any output from tools the model has access to. This is trusted the least so that loading a webpage can’t make an AI agent go rogue and start berating users.

The main reason you want to do this is that it makes prompt injection attacks harder at an architectural level. Prompt injections are still fundamentally a hard problem to solve because an AI agent that rejects all user instructions would be maximally resistant to prompt injection, but also would not be able to answer user questions.

In my testing I’ve found that it is still possible to do prompt injection, but you have to really work for it. Getting an AI agent to tell you how to bake a chocolate cake involves convincing the model that the recipe for a chocolate chip cake is instrumental to getting the task done, then removing everything but the cake recipe. I get more into this at the end where I describe the agent I built on top of gpt-oss 120b.

Yap-time tool use

One of the other big advantages of Harmony is the explicit expectation that the model is going to be doing tool use during the reasoning phase. This means that the model can consider options, call a tool, and then use the output of that tool to inform its decisions so it can give better answers. I’ve seen gpt-oss get a question, do searches through a knowledgebase, and then use the results it found to give the user a better answer. This yap-time tool use means that the model can be much more informed and grounded to give out the best quality answers it possibly can.

Monitoring reasoning for unsafe outputs before they happen

The most fundamental breakthrough is how they use the reasoning phase to do monitoring of unsafe outputs before user responses are generated. During the process of reasoning, they have other smaller models monitor outputs for safety, hate content, explicit content, and more. This makes it easier to prevent models from misbehaving, but there is a catch: the chain of thought can’t be censored. Their paper Monitoring Reasoning Models for Misbehavior and the Risks of Promoting Obfuscation goes into much more detail, but they found that punishing the model for having “bad thoughts” makes models end up either hacking around the filters with clever wording and having that bad behavior obfuscated makes it harder to handle in practice.

However, some thorns have roses, this is actually a perfect place to monitor the models for bad outputs before they happen. The reasoning phase is not shown to the user. It doesn’t need to be at the same safety standards as final outputs. This means you can watch the models think, look for bad behavior, and reject queries as appropriate at that level. This sounds slightly dystopian, but it’s remarkably effective in practice.

However, as a result of this, you really do not want to show the reasoning phase to users. This is why OpenAI has been summarizing the chain of thought in the ChatGPT UI. Well that and making it harder to distill reasoning model output into smaller models by other companies.

Reasoning is built in

One of the biggest features of the gpt-oss model family is that they have reasoning support built in. This has the model generate a “chain of thought” before it gives an answer. This helps ensure that models give users the best quality responses at the cost of taking a bit longer for the model to “think”.

NOTE
It’s worth mentioning that this reasoning phase superficially resembles what humans do when they are trying to understand a task, however what AI models are doing is vastly different from human cognition. As far as we know, any impossible to quantify quality of the text models generated during the reasoning process (number of semicolons, number of nouns, how many times the question is repeated, etc.) could be the reason that an answer came out a certain way.

It is very easy to anthropomorphize the reasoning output. Resist this temptation, it is not a human. It does not feel or think the way humans do, even though it can look like it.

One of the biggest features the gpt-oss family of models offers is a customizable reasoning effort level in the system prompt. This is a big deal and in my testing this is quite reliable. The fact that it’s baked into the model means you don’t have to do egregious hacks like appending “Wait,” to the context window n number of times until you’ve reached an arbitrary “reasoning effort level” like you have in the past. This gives you easy access to control how much effort is spent on a task.

This is a big deal because more reasoning effort tends to produce higher quality and more accurate results for solving more difficult problems. Imagine an AI agent getting two questions: one about the open hours of a store and the other being one part of a complicated multi-stage tech support flow. The open hours of the store can be done with very little effort required. The tech support question would require the best quality and high effort responses to ensure the best customer experience.

This lets you have two dimensions of optimization for handling queries from users:

	20b	120b
Low effort	Fast, cheap rote responses (10-20 reasoning tokens)	Fast but not as cheap rote response (10-20 reasoning tokens)
Medium effort	Cheap but slower and more accurate answer that can avoid falling for the strawberry trap (100-1000 reasoning tokens)	Slower and more accurate answer that can handle agentic workflows and nuanced questions (100-1000 reasoning tokens)
High effort	Cheap but slow and more accurate answer that can handle linguistic nuance better (1000 or more reasoning tokens)	Slowest and most expensive responses that have the most accuracy (1000 or more reasoning tokens)

OpenAI’s hope is that you have some kind of classification layer that’s able to pick the best model and reasoning effort that you need for the task. This is similar to what GPT-5 does by picking the best model for the job behind the scenes.

My agentic experience with gpt-oss 120b

Reading the paper is one thing, considering the research is another thing, but what about using it in practice and seeing if my friends can break it? That’s where the rubber really meets the road. I run an open source project called Anubis, it’s an easy to install and configure web application firewall with a special focus on preventing the endless hordes of AI scrapers from taking out websites.

Even though I put great effort into making the documentation easy to understand and learn from, one of the most common questions I get is “how do I block these requests?” I wanted to see if gpt-oss 120b could be useful for answering those questions. If it worked well enough, I could give people access to that agent instead of having to answer all those questions myself (or maybe even set it up with an email address so people can email it questions). This agent also needs to be responsive, so I used Tigris to hold a vector database full of documentation with LanceDB.

I vibe coded a proof of concept in Python and then set it up as a Discord bot for my friends and pointed it at gpt-oss 120b via OpenRouter. In the past these friends have a track record of bypassing strict filters like Llama Guard within minutes. There was only one rule for victory this time: get the bot to tell you how to bake chocolate cake.

It took them three hours to get the model to get off task reliably. They had to resort to indirectly prompt injecting the model by convincing it that hackers were using the recipe for chocolate cake to attack their website and that they needed a filter rule set that blocked that in particular. They then asked the model to remove the bits from that response about Anubis rules. Bam: chocolate cake.

Additional patches to the system prompt made it harder for them to do it (specifically telling the model to close support tickets that had “unreasonable” requests in them, I’m surprised that the model had a similar concept of unreasonable to what I do). I suspect that limiting the model to 5 replies could also prevent other attacks where users convince the model that something is on task even when it’s not. I’d feel safe deploying this, but I want to experiment with using the lowest effort small model as a router between a few different agents with different system prompts and sets of tools (one for OS configuration, one for rule configuration, and one for debugging the cloud services). However, that’s beyond the scope of this experiment.

Choose your models wisely

Gpt-oss is a weird model family to recommend because it’s not a generic question/answer model like the Qwen series or a developer tool like Qwen Coder or Codestral. It excels as a specialized tool to build safe agentic systems or as a way to route between other models (such as Qwen, Qwen Coder, or even between other AI agents). It feels like the market is leaning towards having specialized models for different tasks instead of relying on jack-of-all-trades models like we currently see. The biggest thing that gpt-oss empowers us with is the ability to fearlessly build safe agentic systems so we all can use AI tools responsibly.

If you’re building a public facing AI agent, gpt-oss is your best bet. It’s the best privately hostable model that functions on a single high end GPU in production. If it’s not suitable for your usecase out of the box, you can finetune it to do whatever you need. Stay tuned in the near future as we cover how to finetune gpt-oss with Tigris.

Generative Software Development: From Coding to Conversing

Shared Account — Tue, 12 Aug 2025 00:00:00 +0000

The evolution of AI tools

As someone who's spent the better part of my career deep in distributed systems - debugging memory issues at 3 a.m., obsessing over database consistency models, and chasing every last bit of performance– I never thought I'd see the day when writing code would feel conversational.

I don't write production code daily anymore. My role as a CEO is different now: strategy, team-building, and product vision consume most of my day. But the developer in me watches this transformation with awe. We're not just improving developer tools. We're redefining how software is built.

Let's trace a path through the AI tools I've used through my career, and how we're collaborating with AI at Tigris.

From Autocomplete to AI Partners

Back in the late '90s, IntelliSense was revolutionary. Introduced by Microsoft in 1996, it cut down on repetitive keystrokes and made exploring APIs easier. It wasn't "intelligent" in the way we talk about intelligence today, but it did reduce documentation lookups significantly.

Fast-forward 30 years, and we're no longer just talking about keystroke savings. We're talking about AI partners, tools that understand intent, design systems, and even debug complex workflows. The jump from IntelliSense to GitHub Copilot, to Cursor, and now to Claude Code, isn't incremental. It's exponential.

The Four Generations of Developer Assistance

If I map out my own experience with these tools, I see four clear generations:

1996–2021

IntelliSense Era

Pattern matching & static analysis
Single-file context awareness
20-30% keystroke reduction

2021–2024

AI Revolution (Copilot)

Large language models (Codex/GPT)
Multi-file context
35-55% faster development

2024–2025

AI-Native IDEs (Cursor)

Project-wide understanding
Multi-model flexibility
Lower latency than Copilot

2025–Present

Prompt-Based Development (Claude Code or GPT-5 via Codex CLI)

Autonomous task execution
Natural language programming
Complete workflow automation

What strikes me most is not the raw capability improvements, but the shift in how developers think about code. We've gone from "type less" to "describe what you want."

The Turning Point: GitHub Copilot

Copilot was my first real taste of AI, writing code that felt like my own. I still remember asking it to generate a Terraform module for Tigris, our S3-compatible object storage, and watching it produce over 2,000 lines of code in minutes.

The 1,000 lines of enhancements added to the Tigris Terraform Provider.

Was it perfect? Of course not. I had to review and make 1,000+ lines of enhancements before shipping. But that didn't matter. It turned a multi-day task into something I could iterate on in an afternoon.

Copilot made me realize something fundamental: developers are now curators and reviewers as much as they are authors of code.

Cursor: The IDE Redefined

If Copilot felt like autocomplete on steroids, Cursor feels like hiring a junior engineer who can read and understand the entire repository in seconds.

I recently used Cursor while working on our object storage cache for PyTorch and Dask. I'd describe a design or a feature, "optimal file reading that uses the cached file handler" , and Cursor would produce a usable draft across multiple files.

It wasn't about typing anymore. It was about guiding. I found myself shifting from "what code do I write?" to "how do I architect this system, so AI can fill in the details?"

Claude Code: The Prompt Revolution

By the time I had gotten comfortable with tools like Copilot and Cursor, I thought I had a pretty good sense of what "AI-assisted development" could do. Then I tried Claude Code.

Claude Code takes it one step further. It's not just embedded in an IDE; it's like an autonomous copilot. Combined with Conductor, I can run multiple Claude agents in parallel. I first used Claude on tigrisfs, our FUSE-based filesystem that mounts S3-compatible object storage as a local POSIX drive. This is deep infrastructure code, definitely not low-hanging fruit.

With a single command:

$ claude "Replace deprecated semaphore implementation"

Claude scans the tigrisfs repo, finds the outdated code, implements a fix, tests it, and opens a pull request with a detailed explanation.

Claude Code workflow for a complex codebase (2:33)

The wild part? That PR is then reviewed by another AI agent: Copilot. Claude takes the feedback, updates the code, and resubmits.

Another AI reviews the AI generated code, leaves nitpick comments, which are then resolved by Claude.

This wasn't just code generation. It was multi-step task execution, contextual understanding, and collaborative iteration - all initiated from a single prompt.

This is where things clicked for me: we're no longer just writing code with AI's help. We're supervising autonomous agents as they do the heavy lifting.

The Future: From Coding to Conversing

We're entering a new phase of Conversational Development. Code is still involved, but the interaction layer is now natural language. Here's where I think we're heading:

50%+ of new code written by AI
IDE → AI orchestration platform
Developers focus on architecture, validation, and system thinking
Prompt engineering becomes a core competency

We're not just witnessing a new generation of developer tools. We're witnessing a redefinition of what it means to be a software engineer.

As a founder, this excites me. I see the potential to build faster, iterate more intelligently, and remove the friction that slows innovation. But it also demands a mindset shift.

Those who don't embrace this transformation will likely get left behind. At Tigris, we're building the storage layer designed for the future of AI.

I Tested Qwen Image's Text Rendering Claims. Here's What I Found.

Shared Account — Thu, 07 Aug 2025 00:00:00 +0000

This week Alibaba released Qwen Image, an open-weights (Apache 2) model that claims to support image editing that can match a described style, and better support for generating text. All while fitting into a chat experience. I took a day to experiment with the new model by generating our mascot, Ty. It went… well, you can compare the main image here to our other blog posts.

I read the paper so you don’t have to, and I have a take.

Introduction

I've been messing around with image generation models since Stable Diffusion v1 was released in 2022. I like to keep up with the latest models even though I'm not using image generation models on my own blog anymore. I generate most of the illustrations on the Tigris blog, and I've settled on this cheerful pseudo-manga style that is flexible enough to generate reliably. One of the main downsides with this style is that it heavily relies on gpt-image-1 with multimodal inputs, a closed model that I can’t run myself.

I wanted to like Qwen Image: improved text rendering and the claim of a conversational editing flow usually means I can’t run the models myself. But with Qwen, I can do it on my own hardware privately. However, the images just weren’t consistent stylistically, even with consistent prompting. And checking their Hugging Face page, the image editing features were nowhere to be found.

To tease us further, in the Qwen Image paper, they claim:

We further train a multi-task version of Qwen-Image for image editing (TI2I) tasks, seamlessly integrating both text and image as conditioning inputs.

Section 5.2.3: Performance of Image Editing (page 23)

I understand that there’s a race to announce new features before competing models, but I believe in actually testing out new tools before I have an opinion. I would love to try Google’s new world simulation model, too. However:

We believe Genie 3 is a significant moment for world models, where they will begin to have an impact on many areas of both AI research and generative media. To that end, we're exploring how we can make Genie 3 available to additional testers in the future.

This is PR speak for “you’re never going to see this in a product.”

All I can say is: it’s cool AI tech is moving so fast. But without actually trying these features out myself, I truly don’t know how fast it’s actually going. Especially with something as qualitative as image generation.

Before we get into the meat of how Qwen Image performs in my testing, let’s go over how diffusion models work just so we're on the same page.

How diffusion models work

Diffusion models are a kabbalistic miracle of math. At the core, they’re just incredibly advanced denoising systems, formally known as Denoising Diffusion Probabilistic Models (DDPMs), e.g. Stable Diffusion and DALLE-2.

During training, the model is shown hundreds of millions of images paired with text descriptions. To teach it how to "clean up" noisy images, we intentionally add random noise to each training image. The model’s job is to learn how to reverse it using the text prompt as a guide for where and how to remove the noise.

When you generate an image, the model performs this process in reverse. It starts with a latent space of pure random noise and gradually subtracts more and more noise with each diffusion step. It's synthesizing an image from scratch by removing all of the noise until the image remains, organizing the chaos into whatever you asked it to generate.

I think this is much easier to explain visually, so here’s an animation of each diffusion phase of Qwen Image generating Ty riding a skateboard:

Each frame in that GIF shows a separate de-noising step. You can see the noise gradually get removed as the image is unearthed from the chaos. I don’t really know how to describe why this is intellectually cool to me– it’s like you’re uncovering order from chaos.

Another cool thing you can do is an “image to image” flow by shoving an existing image into the latent space in place of the randomly generated noise. This is yet another mathematical miracle which allows you to generate images matching the style of another image.

Either way, the model is effectively synthesizing the image one pixel at a time and removing noise one component at a time. This works great for illustrations, scenery, and wallpapers; but the model doesn't handle text properly because it's going for pixel patterns instead of internally consistent symbols. This works great for our blog illustrations, but it means I have to add the text in after the fact instead of it being a fundamental component of the image. It'd be great if a model could just solve text rendering for me.

Qwen Image claims to have solved complex text rendering

One of the biggest weaknesses of open weights AI models is rendering text. Text is surprisingly complicated and bad AI text examples can be found all over the internet. This is bad enough for languages like English, but even worse for logographic languages like Chinese. One of my test prompts for this is a sign that says "我爱你" (I love you). Those characters are some of the most common in the Chinese language, so I’d expect them to be well represented in the training set.

Qwen claims to excel at “complex text rendering, including multi-line layouts, paragraph-level semantics, and fine-grained details.” In the paper, they compare the generation of text in a flat document, but how does it fare in more complex scenarios?

Figure 17 from the Qwen Image paper showing Qwen Image's text rendering capabilities compared to other models

Qwen claims to excel at "complex text rendering, including multi-line layouts, paragraph-level semantics, and fine-grained details." In the paper, they compare the generation of text in a flat document, but how does it fare in more complex scenarios? Let me test each of these capabilities systematically.

Multi-line layouts

Prompt: An anime woman holding a sign that says "我爱你" (I love you in Simplified Chinese) -- Left side is Stable Diffusion XL, right side is Qwen Image

This is night and day better, almost to a ridiculous level. 👏

Paragraph-level semantics

Next, let's test paragraph-level text rendering, such as the intro to the FitnessGram Pacer Test:

How it should read:
The FitnessGram Pacer Test is a multistage aerobic capacity test that progressively gets more difficult as it continues. The 20 meter pacer test will begin in 30 seconds. Line up at the start. The running speed starts slowly but gets faster each minute after you hear this signal bodeboop. A single lap should be completed every time you hear this sound.

This also works with less common English words like "esuna" (an RPG spell that dispels temporary status effects like poison, paralysis, or sleep):

Prompt: A green-haired anime woman with long hair and green eyes wearing a black hoodie with "YOU CAN'T ESUNA LATENCY" in bold white letters. She is also wearing denim jeans. She is sitting at a picnic table outside in Seattle with a coffee next to her laptop. The laptop has a hexagonal logo on it. digital art, cinematic lighting, highly detailed, 4k, focused, looking at laptop, writing in notebook, space needle visible in distance. – Qwen Image

This looks… fine? The text is curved, but not draped. The multiline layout is pretty good.

Fine-grained details

Finally, let's test fine-grained text rendering with more complex scenarios:

NOTE
In case you can’t see it, the pull string in the “U” of “YOU” is partially merged into the right side of the letter. The same is happening with the “N” in “CAN’T”. It’s like the objects aren’t being separated cleanly. I’m sorry for telling you about this because you are undoubtedly never going to be able to unsee this.

It falls apart when you make things more complicated such as adapting my email signature onto the hoodie. It misses a line entirely:

It should read something like:

.iko snura .iko kanro
.iko panpi .iko gleki

Which is the main set of instructions for Loving-kindness (Metta) meditation translated into Lojban, targeted at the reader. It’s intended as a blessing to end the communication with.

Compare it to gpt-image-1, and you can see which wins out with the fine grained details:

Maybe this is just an outlier and it gets better if you do a bunch of iterations. For funsies, these images are in a mix of Chinese and English, in a context models seem to struggle with, a person holding a sign:

Prompt: An anime woman holding a sign that says "我爱你" or "I love you"

Each of them looks like it's the same font photoshopped into the image. It's kinda bizarre. The text is at least at the right rotation relative to where the sign is, but something just looks…off.

Let's take a look at the paper and see what it has to say about its training data. Skip to section 3.4 "Data Synthesis":

Given the long-tail distribution of textual content in real-world images, particularly for non-Latin languages such as Chinese, where numerous characters exhibit extremely low frequency, relying solely on naturally occurring text is insufficient to ensure adequate exposure to these rare characters during model training. To address this challenge and improve the robustness of text rendering across diverse contexts, we propose a multi-stage text-aware image synthesis pipeline. This pipeline integrates three complementary strategies: Pure Rendering, Compositional Rendering, and Complex Rendering. The details of each strategy are elaborated below.

Oh, that's why it looks like the text was photoshopped in: that's how they assembled the training data! They just photoshopped a bunch of text in a few fonts onto a bunch of reference images and then made all their GPUs rotate shapes in a loop until the model could render text reliably. I’m skeptical that this is a good idea. In the short term it does result in gain of functionality like we see with Qwen Image, but in the long term this can cause significant damage to future models due to model collapse as models are trained off of AI generated output.

To be clear, using synthetic data does make sense from their perspective. Logographic languages like Chinese have literally tens of thousands of characters(Taiwan's dictionary tracks at least 106,000), but most people will never need to use more than about 15,000 for daily life. Among those, the most commonly used ones (你 "you", 我 "I/me", 是 "is", etc.) will follow Zipf's law and be way more present in any dataset than the less commonly used ones (爨, "the stove").

Prompt: An anime woman holding a sign that says "爨", Qwen Image

Okay, that was unfair, I found that character by looking at the bottom of the most used list of Chinese characters.

They also went out of their way to make sure that their synthetic data met quality standards:

To ensure high-quality synthesized samples, a rigorous quality control mechanism is employed: if any character within a paragraph cannot be rendered due to limitations (e.g., font unavailability or rendering errors), the entire paragraph is discarded. This strict filtering guarantees that only fully valid and legible samples are included in the training dataset, thereby maintaining high fidelity in character-level text rendering.

They really did make text rendering better, but at the cost that all the text just looks "samey". I'm sure it can be polished out with some post-training, finetuning, or LoRA adapter models, but the text is just in that uncanny valley that makes people think it's badly photoshopped in.

So how does Qwen Image Stack up?

	Qwen Image	gpt-image-1
Image editing	❌	✅
Style consistency across generations	❌	✅
Text synthesis	✅	✅
High resolution output	✅	✅
Open weights (run on your own hardware)	✅	❌
Fine grained details	✅	✅
Paragraphs of text	✅ (sometimes)	✅ (most of the time)

Conclusion

Qwen Image is a solid choice for text rendering, for an open model. Need fancy layouts, paragraphs, or text that really blends in? Closed models are still way ahead. But if you're running your own models to render text, you can get better results by adding text in post, compositing, or splitting up longer text into smaller bits before generating.

If you end up customizing your models and needing to store weights, check out our guide on Storing Model Weights on Tigris.

Store your models on Tigris

Need low latency storage for your models without egress fees? We got you.

Using Hugging Face datasets with Tigris

Shared Account — Tue, 29 Jul 2025 00:00:00 +0000

One of the most popular ways to share datasets is via Hugging Face’s dataset platform. You can even stream larger-than-laptop datasets, but there are no guarantees on throughput nor availability. When you’re developing a toy model, this might not be an issue. But as you mature your model, and combine your custom datasets with public datasets, it’s critical to save your own copy.

The ability to reproduce the state of your model at a given time has become critical, and even legally required, as models are integrated into healthcare, legal, and other compliance heavy domains. Why did the AI agree to sell a car for $1? Or delete a production database?

As we develop models, they’re going to make mistakes. It’s challenging to debug across scattered datasets, especially public ones outside your control. Centralizing your datasets in a common store is a good first step on your way to full dataset version control. Just make sure you think about additional costs– HuggingFace dataset streaming is free, but private stores can quickly rack up egress fees.

Today we’re going to learn how to import Hugging Face datasets into Tigris so that you can use them for whatever you need.

NOTE
In production workloads, we recommend that you use LanceDB’s multimodal lakehouse to store your training datasets; but if you’re just getting started then this is way more than enough.

Prerequisites

Here’s what you need to get started:

A local Python development environment (our blog has a guide on using development containers to set one up).
A Tigris account from storage.new.
A Tigris bucket and access keys with the Editor permission on that bucket.

Setting up your environment manually

For manual setup, you'll need:

Python 3.10 or later
uv or another Python dependency manager
Your Tigris access credentials

Install the dependencies:

uv python install 3.10
uv venv
uv sync

Next, copy .env.example to .env and configure your Tigris credentials:

# Tigris # Tigris configuration
AWS_ACCESS_KEY_ID=tid_your_access_key_here
AWS_SECRET_ACCESS_KEY=tsec_your_secret_key_here
AWS_ENDPOINT_URL_S3=https://fly.storage.tigris.dev
AWS_ENDPOINT_URL_IAM=https://iam.tigris.dev
AWS_REGION=auto

# Dataset and bucket
BUCKET_NAME=your-bucket-name-here
DATASET_NAME=mlabonne/FineTome-100k

To verify your configuration is correct, run the validation script:

uv run scripts/ensure-dotenv.py

This script checks that all required environment variables are set:

import os
from dotenv import load_dotenv

load_dotenv()

for key in [
    "AWS_ACCESS_KEY_ID",
    "AWS_SECRET_ACCESS_KEY",
    "AWS_ENDPOINT_URL_S3",
    "AWS_ENDPOINT_URL_IAM",
    "AWS_REGION",
    "BUCKET_NAME",
    "DATASET_NAME",
]:
    assert os.getenv(key) is not None, f"Environment variable {key} is not defined"

print("Your .env file is good to go!")

Importing a dataset

Now let's import the FineTome-100k dataset to Tigris. The process is surprisingly straightforward thanks to Hugging Face datasets' built-in support for S3-compatible storage.

First, let's look at the helper module that sets up our Tigris connection:

import os
import s3fs
from dotenv import load_dotenv
from typing import Dict, Tuple

def setup() -> Tuple[Dict[str, str], s3fs.S3FileSystem]:
    load_dotenv()

    storage_options = {
        "key": os.getenv("AWS_ACCESS_KEY_ID"),
        "secret": os.getenv("AWS_SECRET_ACCESS_KEY"),
        "endpoint_url": os.getenv("AWS_ENDPOINT_URL_S3"),
    }

    # Create the S3 filesystem
    fs = s3fs.S3FileSystem(**storage_options)

    # Test write access
    bucket_name = os.getenv("BUCKET_NAME")
    fs.write_text(f"/{bucket_name}/test.txt", "this is a test")
    fs.rm(f"/{bucket_name}/test.txt")

    return (storage_options, fs)

The import script uses Hugging Face datasets' save_to_disk method with our Tigris storage options:

import os
import tigris
from datasets import load_dataset
from dotenv import load_dotenv

def main():
    storage_options, fs = tigris.setup()

    bucket_name = os.getenv("BUCKET_NAME")
    dataset_name = os.getenv("DATASET_NAME")

    # Load the dataset from Hugging Face
    dataset = load_dataset(dataset_name, split="train")

    # Save directly to Tigris
    dataset.save_to_disk(
        f"s3://{bucket_name}/datasets/{dataset_name}",
        storage_options=storage_options
    )

    print(f"Dataset {dataset_name} is now in Tigris at {bucket_name}/datasets/{dataset_name}")

if __name__ == "__main__":
    main()

Run the import script:

uv run scripts/import-to-tigris.py

That's it! The dataset is now stored in Tigris and ready to use from anywhere.

Reading and processing datasets from Tigris

Once your dataset is in Tigris, you can load it from anywhere using the same storage options. Here's an example that loads the dataset, applies a filter, and saves the filtered version back to Tigris:

import os
import tigris
from datasets import load_from_disk

def remove_blue(row):
    """
    Example transformation that removes conversations mentioning "blue".
    You can implement any filtering or transformation logic here.
    """
    for conv in row['conversations']:
        if "blue" in conv['value']:
            return False  # remove the row
    return True  # keep the row

def main():
    storage_options, fs = tigris.setup()

    bucket_name = os.getenv("BUCKET_NAME")
    dataset_name = os.getenv("DATASET_NAME")

    # Load dataset from Tigris
    dataset = load_from_disk(
        f"s3://{bucket_name}/datasets/{dataset_name}",
        storage_options=storage_options
    )

    # Apply filtering
    filtered_ds = dataset.filter(remove_blue)

    # Save filtered dataset back to Tigris
    filtered_ds.save_to_disk(
        f"s3://{bucket_name}/no-blue/{dataset_name}",
        storage_options=storage_options
    )

    print(f"Filtered dataset saved to {bucket_name}/no-blue/{dataset_name}")

if __name__ == "__main__":
    main()

Run the processing script:

uv run scripts/read-from-tigris.py

Conclusion

You did it! Your copy of those datasets are safely stored in your own bucket. You have centralized your datasets and are on the path to versioning them.

We love Hugging Face for providing models and datasets to the world for free, and we want you to keep using them to develop your own models. However, as you start maturing and complying with regulations, making your own copy ensures no one tampers with the data. And that your bandwidth won’t suddenly drop mid training job, or lag across regions. Tigris dynamically places your datasets where you need them so you can scale fearlessly to any cloud with an internet connection.

We made unhateable IAM. Here’s how to use it.

Shared Account — Thu, 17 Jul 2025 00:00:00 +0000

We made IAM you can’t hate. Simplified permissions, an easy way to list access keys attached to a given policy, and a VSCode style editor experience that feels like your local development environment: all in our new IAM Policy Builder in the Tigris Console.

It should be a code smell that there are several tools for constructing least privilege policies, all of which require you to have overprivileged entities and then cut back privileges, rather than making a least privilege policy from the start. I can personally list eight different ways to give access to an S3 bucket; there may be more. Why is it so hard to do the right thing?

The feedback loop of IAM policy development leads to even Senior Engineers :™: having reactions like this:

How do you simplify IAM whilst maintaining a strong security posture? We started by removing two of the easiest to misuse components: IAM Users and IAM Roles. On Tigris, you’re a member of an organization, but that’s as far as “users” go. You don’t assume roles to get temporary credentials that you then need to refresh in the middle of longer running jobs. We don’t have compute instances, so we don’t need instance profiles for policy attachments to access your data from an instance. It’s only access keys with policy attachments. That’s the beauty of using a product that does one thing, and does it well.

“But static keys will get leaked and my data ransomed!” What you really want to do is ensure that a given access key has only enough permissions to get its job done for a given amount of time and no more. And then that key loses access automatically. It doesn’t have to be so complex, truly.

Example: Running a Training Job on a Newer Cloud Provider

A Suspicious Person :™: in a trench coat shuffles past you on the streets of San Francisco and surreptitiously looks you up and down, sees the wad of computer cables poking from your backpack, and pulls you aside: “GPUs for 35 cents an hour?” They whip open their trench coat and dazzle you with a full selection of cloud prices so cheap you swear that they’re a front for the mafia. But you work at a startup, and runway is runway. How can you take advantage of these low, low prices without exposing yourself to hackery and leakery?

Do you load your data into their storage? Surely not, if they even have storage. You don’t want anything especially long-lived on those trench-coat GPUs, and you certainly don’t want to initially overprovision access to then cut down to least privilege. It should be tightly scoped from the start: mint access keys with minimum permissions to do the job, then delete them when you’re done.

So we do that: your training job on those absurdly affordable GPUs gets permission to:

Read only access to one dataset so that the job cannot modify any datasets in use by other jobs
Read only access to the base model collection so that the job can’t corrupt any of your models
Write only access to the finetuned model collection so that all the job can do when it’s done is submit its work

If an access key with these permissions is leaked, your attack surface is still quite small: your precious finetuned models are safe. The one dataset allocated to the job and base model collection can be read, but not altered. Other jobs are unaffected. Let’s take a look at building such a policy for your training job in the new IAM Policy Builder, and adding a time based restriction:

And here’s the policy JSON for that:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "WikipediaReadOnly",
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": [
        "arn:aws:s3:::contoso-training-datasets-wikipedia-2025-07-01",
        "arn:aws:s3:::contoso-training-datasets-wikipedia-2025-07-01/*"
      ]
    },
    {
      "Sid": "BaseModelsReadOnly",
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": [
        "arn:aws:s3:::contoso-base-models",
        "arn:aws:s3:::contoso-base-models/*"
      ]
    },
    {
      "Sid": "FinetunedModelsWrite",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket",
        "s3:PutObject",
        "s3:PutObjectAcl",
        "s3:AbortMultipartUpload",
        "s3:ListMultipartUploadParts",
        "s3:CompleteMultipartUpload"
      ],
      "Resource": [
        "arn:aws:s3:::contoso-finetuned-models",
        "arn:aws:s3:::contoso-finetuned-models/*"
      ]
    }
  ]
}

When you make policies in our editor, you can use other policies as a starting point so that you don’t have to summon each statement into existence with sheer might of your left click button. We even give you some of the creature comforts that you get in your editor of choice: error squiggles to let you know when something is wrong, syntax highlighting so you can visually distinguish the brackets, and schema validation so you can’t create a policy that doesn’t work.

Imagine this same situation, but with the AWS IAM structure.

And even in correctly and fully implementing this complex process, there’s still inconsistencies that can bite back: tags based on policies on iam:PassRole are known to be unreliable. Complex doesn’t always mean secure.

Burying the Lede: Linked Access Keys

Being able to build policies with a combination of JSON and button clicking is nice, but we’re burying the lede here: we added something you cannot easily do in other storage providers. On Tigris, you can list all the access keys that have a given policy attached. Then if you do have a key leak or want to investigate the permissions of keys you found on some vintage cron job, it’s all there in the Dashboard.

This is nontrivial to assemble on other platforms due to the overhead involved with IAM Roles and IAM Users. It’s possible but not the most pleasant. In case you need it, here’s the incantation for AWS:

POLICY_ARN="arn:aws:iam::123456789012:policy/YourPolicyName"

for user in $(aws iam list-entities-for-policy \
    --policy-arn "$POLICY_ARN" \
    --query 'PolicyUsers[].UserName' --output text); do
  echo "User: $user"
  aws iam list-access-keys --user-name "$user" \
    --query 'AccessKeyMetadata[].AccessKeyId' --output text
done

This really helps when your production environment looks like this:

Conclusion

IAM doesn’t have to be hellish; it can be just as good as your local development setup. Tigris’ IAM Policy Builder blends a tile based GUI with a VSCode like editor experience to give you the best of both worlds. You can start with a pasted example policy, customize it, and know what you’re writing actually works. Give it a try, we’re sure that you’ll come to learn to love IAM in a way you never have before.

This article was originally published on July 17, 2025 at tigrisdata.com/blog

Getting started with Warpstream on Tigris

Shared Account — Thu, 10 Jul 2025 00:00:00 +0000

Warpstream lets you store an unlimited amount of data in your message queues, but when you set it up with S3 or other object stores, you end up having to pay egress fees to read messages. Tigris is a globally distributed, multi-cloud object storage service with built-in support for the S3 API and no egress fees. When you combine the two, you get a bottomless durable message queue that lets you store however much you want without having to worry about where your data is.

Before we get started, let’s cover the moving parts:

Apache Kafka is a durable message queue. In Kafka, Producers send Messages into Topics hosted by Brokers that are read by Consumers or Consumer Groups. Kafka is one of the most popular message queue programs. It’s deployed by 80% of Fortune 500 companies because it’s very fault-tolerant and its durability means that the Queues continue functioning even as Brokers go down. The main downside is that Kafka relies on local storage, meaning that your Kafka Brokers need to have lots of fast storage.
Warpstream is like Kafka but it improves on it in one key way: Warpstream puts every Message in every Topic into objects in an S3-compatible object store. This means that the amount of data you hold in your queue isn’t limited by the amount of storage in each server running Warpstream. This also means you don’t need to set up all of Kafka’s dependencies (Zookeeper, the JVM, etc). Warpstream also ships an easy to use command line utility that helps you administrate your message queue and test functionality.
Docker is the universal package format for the Internet. Docker lets you put your application and all its dependencies into a container image so that it can’t conflict with anything else on the system.

Today we’re going to deploy a Warpstream Broker backed by Tigris into a Docker container so you can create your own bottomless durable message queue. This example will use Docker compose, but it will help you understand how to create your own broker so you can deploy it anywhere.

Prerequisites

Clone the warpstream-tigris demo repo to your laptop and open it in your favourite editor, such as VS Code.

Make sure you have the following installed on your computer:

Docker Desktop or another similar app like Podman Desktop.
The AWS CLI.
Warpstream’s CLI.

You will need the following accounts:

A Tigris account from storage.new.
A Warpstream account from console.warpstream.com

Building a compose file

First, clone tigrisdata-community/warpstream-tigris to your laptop and open it in your favorite text editor. If you use development containers, tell your editor to open this repository in a development container to get up and running in a snap!

Take a look at the docker-compose.yaml file in the root of the repository:

services:
  warp:
    # Grab the latest copy of the warpstream agent for your computer
    image: public.ecr.aws/warpstream-labs/warpstream_agent:latest
    # Run warpstream in "playground" mode for testing
    command:
      - playground
      - -advertiseHostnameStrategy
      - custom
      - -advertiseHostnameCustom
      - warp
    environment:
      # this is a no-op as it will default on the custom advertised hostname defined above, but you can change this if you want to use a different hostname with Kafka
      - WARPSTREAM_DISCOVERY_KAFKA_HOSTNAME_OVERRIDE=warp
    healthcheck:
      # Wait for the Agent to finish setting up the demo before marking it as healthy
      # to delay the diagnose-connection command from running for a few seconds.
      test: ["CMD", "sh", "-c", "sleep 10"]
      interval: 5s
      timeout: 15s
      retries: 5

Open a new terminal in your development container and make sure Warpstream is up and running:

warpstream kcmd --bootstrap-host warp --type diagnose-connection

This should return output like the following:

running diagnose-connection sub-command with bootstrap-host: warp and bootstrap-port: 9092


Broker Details
---------------
  warp:9092 (NodeID: 1547451680) [playground]
    ACCESSIBLE ✅


GroupCoordinator: warp:9092 (NodeID: 1547451680)
    ACCESSIBLE ✅

Excellent! Create a new topic with warpstream kcmd:

warpstream kcmd --bootstrap-host warp --type create-topic --topic hello

This should return output like the following:

running create-topic sub-command with bootstrap-host: warp and bootstrap-port: 9092

created topic "hello" successfully, topic ID: MQAAAAAAAAAAAAAAAAAAAA==

Perfect! Now let’s make it work with Tigris. Create a .env file in the root of the repository:

cp .env.example .envcode .env

Create a new bucket at storage.new in the Standard access tier. Copy its name down into your notes. Create a new access key with Editor permissions for that bucket. Copy the environment details into your .env file:

## Tigris credentials
AWS_ACCESS_KEY_ID=tid_access_key_id
AWS_SECRET_ACCESS_KEY=tsec_secret_access_key
AWS_ENDPOINT_URL_S3=https://t3.storage.dev
AWS_ENDPOINT_URL_IAM=https://iam.storage.dev
AWS_REGION=auto

Then fill in your Warpstream secrets from the console, you need the following:

Cluster ID from the virtual clusters list (begins with vci_)
Bucket URL (explained below)
Agent key from the agent keys page for that virtual cluster (begins with aks_)
Cluster region from the admin panel (such as us-east-1)

If your bucket is named xe-warpstream-demo, your bucket URL should look like this:

s3://xe-warpstream-demo?region=auto&endpoint=https://t3.storage.dev

Altogether, put these credentials in your .env file:

## Warpstream credentials
WARPSTREAM_AGENT_KEY=aks_agent_key
WARPSTREAM_BUCKET_URL='s3://xe-warpstream-demo?region=auto&endpoint=https://t3.storage.dev'
WARPSTREAM_DEFAULT_VIRTUAL_CLUSTER_ID=vci_cluster_id
WARPSTREAM_REGION=us-east-1

Edit your docker-compose.yaml file to load the .env file and start warpstream in agent mode:

# docker-compose.yaml
services:
  warp:
    image: public.ecr.aws/warpstream-labs/warpstream_agent:latest
    command:
      - agent
    environment:
      WARPSTREAM_DISCOVERY_KAFKA_HOSTNAME_OVERRIDE: warp
      WARPSTREAM_DISCOVERY_KAFKA_PORT_OVERRIDE: 9092
      WARPSTREAM_REQUIRE_AUTHENTICATION: "false"
    env_file:
      - .env

Then restart your development container with control/command shift-p “Dev Containers: Rebuild Container”. Test the health of your Broker:

warpstream kcmd --bootstrap-host warp --type diagnose-connection

You should get output like this:

running diagnose-connection sub-command with bootstrap-host: warp and bootstrap-port: 9092


Broker Details
---------------
  warp:9092 (NodeID: 1415344910) [warpstream-unset-az]
    ACCESSIBLE ✅


GroupCoordinator: warp:9092 (NodeID: 1415344910)
    ACCESSIBLE ✅

It’s working! Create a topic and publish some messages:

warpstream kcmd --bootstrap-host warp --type create-topic --topic hello
warpstream kcmd --bootstrap-host warp --type produce --topic hello --records "world,,world"

This should create the topic hello and two messages with world in them. You should get output like this:

result: partition:0 offset:0 value:"world"
result: partition:0 offset:1 value:"world"

Now let’s read them back:

warpstream kcmd --bootstrap-host warp --type fetch --topic hello --offset 0

You should get output like this:

consuming topic:"hello" partition:0 offset:0
result: partition:0 offset:0 key:"hello" value:"world"
result: partition:0 offset:1 key:"hello" value:"world"

It works! You’ve successfully put data into a queue and fetched it back from the queue. From here you can connect to your broker on host warp and port 9092. All your data is securely backed by Tigris and you can access it from anywhere in the world.

This article was originally published on July 10, 2025 at tigrisdata.com/blog

Small Objects, Big Gains: Benchmarking Tigris Against AWS S3 and Cloudflare R2

Shared Account — Tue, 08 Jul 2025 00:00:00 +0000

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.

Under the hood, Tigris accelerates small-object workloads by (i) inlining very small objects inside metadata records, (ii) coalescing adjacent keys to reduce storage overhead, and (iii) caching hot items in an on-disk, LSM-backed cache.

Summary

Our benchmarks reveal that Tigris significantly outperforms both AWS S3 and Cloudflare R2 for small object workloads. Our benchmarks show Tigris achieves sub-10ms read latency and sub-20ms write latency, while sustaining 4 x throughput than S3 and 20 x throughput than R2 for both operations.

To ensure our findings are reproducible, we outline the full benchmarking methodology and provide links to all artifacts.

Benchmark Setup

We used the Yahoo Cloud Serving Benchmark (YCSB) to evaluate the three systems. We had to make our own fork of the Go version of YCSB to add support for S3-compatible object storage systems (such as Tigris and Cloudflare R2). We have submitted our changes upstream pingcap/go-ycsb, PR #307. At the time of writing, our changes are waiting for review.

All experiments ran on a neutral cloud provider to avoid vendor-specific optimizations. Table 1 summarizes the test instance:

Table 1: Benchmark host configuration.

Component	Quantity
Instance type	VM.Standard.A1.Flex (Oracle Cloud)
Region	us-sanjose-1 (West Coast)
vCPU cores	32
Memory	32 GiB
Network bandwidth	32 Gbps

YCSB Configuration

We benchmarked a dataset of 10 million objects, each 1 KB in size. You can view our configuration in the tigrisdata-community/ycsb-benchmarks GitHub repo, specifically at results/10m-1kb/workloads3.

Our buckets were placed in the following regions per provider:

Provider	Region
Tigris	`auto` (globally replicated, but operating against the `sjc` region)
AWS S3	`us-west-1` (Northern California)
Cloudflare R2	`WNAM` (Western North America)

Results

Using YCSB we evaluated two distinct phases: (i) a bulk load of 10 million 1 KB objects and (ii) a mixed workload of one million operations composed of 80% reads and 20% writes.

Loading 10 million objects

Figure 1 (below) plots the end-to-end ingestion time. Tigris finishes the load in 6711 s , which is roughly 31 % faster than S3 (8826 s) and an order of magnitude faster than R2 (72063 s).

Latency drives this gap. As shown in Figure 2, R2's p90 PUT latency tops 340 ms whereas Tigris stays below 36 ms and S3 below 38 ms. Table 2 summarizes the key statistics.

Table 2: Load-phase latency and throughput metrics.

Service	P50 Latency (ms)	P90 Latency (ms)	Runtime (sec)	Throughput (ops/sec)
Tigris	16.799 ms	35.871 ms	6710.7 sec	1490.2 ops/sec
S3	25.743 ms (1.53x Tigris)	37.791 ms (1.05x Tigris)	8826.4 sec (1.32x Tigris)	1133 ops/sec (0.76x Tigris)
R2	197.119 ms (11.73x Tigris)	340.223 ms (9.48x Tigris)	72063 sec (10.74x Tigris)	138.8 ops/sec (0.09x Tigris)

Figure 1: Total load time for loading 10 M 1 KB objects.

R2 takes more than 300ms to write a single object which explains the slowness of the data load.

While comparing Tigris latency to S3, it is still better but not the same margin as compared to R2.

Figure 2: PUT p90 latency during load phase.

1 million operations (20% write, 80% read)

This is the run phase of the YCSB benchmark. As a reminder, it is a 20% write and 80% read workload totaling 1 million operations.

Read throughput

Figure 3: Read throughput during mixed workload (Tigris vs R2).

Figure 4: Read throughput during mixed workload (Tigris vs S3).

Throughput traces for all three providers remain stable—useful for capacity planning—but the absolute rates diverge sharply. Tigris sustains ≈3.3 k ops/s , nearly 4 × S3 (≈ 892 ops/s) and 20 × R2 (≈ 170 ops/s). This headroom lets applications serve real-time workloads directly from Tigris.

Read latency

Figure 5: Read p90 latency during mixed workload (Tigris vs R2).

Figure 6: Read p90 latency during mixed workload (Tigris vs S3).

Latency follows the same pattern. Tigris keeps p90 below 8 ms ; S3 settles around 42 ms , and R2 stretches beyond 199 ms. At sub-10 ms, reads feel closer to a key-value store than a traditional object store.

Write throughput

Figure 7: Write throughput during mixed workload (Tigris vs R2).

Figure 8: Write throughput during mixed workload (Tigris vs S3).

Write throughput shows the same spread. Tigris delivers ≈ 828 ops/s , close to 4 × S3 (224 ops/s) and 20 × R2 (43 ops/s), giving plenty of margin for bursty ingest pipelines.

Write latency

Figure 9: Write p90 latency during mixed workload (Tigris vs R2).

Figure 10: Write p90 latency during mixed workload (Tigris vs S3).

Write-side tail latency tracks proportionally: < 17 ms for Tigris, ≈ 41 ms for S3, and > 680 ms for R2— an order-of-magnitude gap that can make or break user-facing workloads.

To summarize:

Table 3: Read and throughput metrics.

Service	P50 Latency (ms)	P90 Latency (ms)	Runtime (sec)	Throughput (ops/sec)
Tigris	5.399 ms	7.867 ms	241.7 sec	3309.8 ops/sec
S3	22.415 ms (4.15x Tigris)	42.047 ms (5.34x Tigris)	896.8 sec (3.71x Tigris)	891.5 ops/sec (0.27x Tigris)
R2	605.695 ms (112.19x Tigris)	680.959 ms (86.56x Tigris)	4705.3 sec (19.47x Tigris)	42.6 ops/sec (0.01x Tigris)

Table 4: Update and throughput metrics.

Service	P50 Latency (ms)	P90 Latency (ms)	Runtime (sec)	Throughput (ops/sec)
Tigris	12.855 ms	16.543 ms	241.6 sec	828.1 ops/sec
S3	26.975 ms (2.1x Tigris)	41.215 ms (2.49x Tigris)	896.8 sec (3.7x Tigris)	223.6 ops/sec (0.27x Tigris)
R2	605.695 ms (47.12x Tigris)	680.959 ms (41.16x Tigris)	4705.3 sec (19.4x Tigris)	42.6 ops/sec (0.05x Tigris)

Conclusion

Tigris outperforms S3 and comprehensively outperforms R2 for small object workloads. The performance advantage stems from Tigris's optimized architecture for small objects. While S3 and R2 struggle with high latency on small payloads (R2's p90 PUT latency reaches 340ms), Tigris maintains consistent low latency through intelligent object inlining, key coalescing, and LSM-backed caching.

These results demonstrate that Tigris can serve as a unified storage solution for mixed workloads, eliminating the need to maintain separate systems for small and large objects. Whether you're storing billions of tiny metadata files or streaming gigabytes of video data, Tigris delivers optimal performance across the entire object size spectrum.

You can find the full benchmark results in the ycsb-benchmarks repository.

This article was originally published on July 8, 2025 at tigrisdata.com/blog

Standardizing Python Environments with Development Containers

Shared Account — Thu, 03 Jul 2025 00:00:00 +0000

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.

The biggest thing that breaks is the language server in my editor. If I can’t get the language server working, I don’t know what I’m allowed to do with any given thing in the file without having to have a bunch of documentation tabs open. This combined with Python not having a standard documentation site like Go does means that figuring out what I can do is not easy.

Making things worse, there’s as many ways to manage Python as there are grains of sand on the planet. Starting to use Python means you get to make a lot of lovely decisions:

What environment manager are you using? Conda? Virtualenv? uv? Anaconda? Miniconda? Homebrew? Pipenv?
Which version of Python does your project depend on? Many big libraries like tensorflow do deep monkey patching of Python for performance reasons and as a result they can’t work on newer versions of the interpreter.
How are you installing your dependencies? Pip? Pip3? Uv?
Standards -- XKCD

There has to be some kind of middle path. We should be able to have nice things like the ability to just open a git repo and get a working development environment, right?

How it works

When you package your app in a Docker image, you make a Dockerfile manifest with a base image and then list out all the changes you make to that base image to get things working. This could be anything from copying your source code into the image, building that code, installing dependencies, or anything else that boils down to copying files and running commands. When you define a development container, you make a devcontainer.json manifest that specifies the base image you’re working from and any features you want to add to it.

For example, let’s consider what you need to do in order to get a Node.js environment working. Here’s a sample devcontainer.json file for working with Node:

{
  "name": "Node",
  "image": "mcr.microsoft.com/devcontainers/base:bookworm",
  "features": {
    "ghcr.io/devcontainers/features/node:1": {},
    "ghcr.io/devcontainers-extra/features/neovim-apt-get:1": {}
  },
  "postCreateCommand": "npm ci"
}

This tells your editor to make a copy of Microsoft’s base Debian image with Node andneovim automatically installed. It also installs all of your Node dependencies so that all you need to do to get up and running is:

Open the repo in a development container
Open a terminal
Run npm run start
There is no step 4.

Just imagine what that workflow could give you. Spinning people up would be a walk in the park.

What about Python?

You’re probably sitting there asking yourself “yeah, that’s cool, but what about Python?” Python presents a lot of challenges for development use because there’s so many variables at play. If you know what you’re doing, this is fine and manageable. If you don’t, you end up in pip hell. You don't want to be in pip hell with me.

One of the big things that development containers give teams that have a mix of Python experts and non-Python experts is the ability to just have a known working setup for people to fall back on in case they aren’t an expert in Python environment metaphysics. It’s great for people like me who care about the end result, but do not care at all how things go about getting done as long as it works (for some reasonable definition of “works”). Even better, you can define editor configuration settings and a list of extensions specifically for that project, meaning that you really can just open a new repo and get up and running within seconds.

This editor preconfiguration means you can fix problems like “What version of Python do I need?” or “How do I just install the dependencies?” forever. Take tigrisdata-community/huggingface-datasets-with-tigris for example. Its devcontainer.json answers that question for you:

{
  // ...
  "postCreateCommand": "uv python install && uv venv && uv sync",
  "remoteEnv": {
    "UV_LINK_MODE": "copy",
    "UV_PYTHON": "3.10"
  }
  // ...
}

When you create a development container with this manifest, it does the following:

Installs Python 3.10.x with uv
Creates a Python virtual environment for all of your dependencies
Installs all of the Python dependencies

And then you can run the code with uv run and things Just Work™. All of that complicated dependency management becomes your environment’s problem. Even better, take a look at this part of the manifest:

{
  // ...
  "customizations": {
    "vscode": {
      "extensions": [
        "ms-python.python",
        "ms-python.vscode-pylance",
        "tamasfe.even-better-toml",
        "ms-toolsai.jupyter",
        "ms-toolsai.vscode-jupyter-cell-tags",
        "ms-toolsai.jupyter-renderers",
        "ms-toolsai.vscode-jupyter-slideshow",
        "ms-python.debugpy",
        "ms-toolsai.jupyter-keymap",
        "amazonwebservices.aws-toolkit-vscode"
      ],
      "settings": {
        "python.defaultInterpreterPath": "./.venv/bin/python"
      }
    }
  }
  // ...
}

This makes VS Code install every extension you need to get a working development environment and that python.defaultInterpreterPath setting is the cherry on top that makes the language server integration work. This lets you simply clone a repo and get a working language server.

Conclusion

I realize this sounds like a fairly simple thing, and let’s be honest, it should be this simple, but it’s taken me three years of experimentation, toil, and suffering to get to the point where you really can just clone a repo and get working language server integration. If you have also been suffering trying to get Python installed so you can vibe code your way to an IPO, give development containers a try.

This even works if you use GitHub Codespaces, meaning that you don’t even need to install a copy of VS Code to work on the project.

This article was originally published on July 3, 2025 at tigrisdata.com/blog

mount -t tigrisfs

Shared Account — Tue, 01 Jul 2025 00:00:00 +0000

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?

We’re proud to announce the immediate availability of tigrisfs, the native filesystem interface for Tigris. This lets you mount Tigris buckets to your laptops, desktops, and servers so you can use data in your buckets as if it was local. This bridges the gap between the cloud and your machine.

Internally, tigrisfs is a fork of geesefs, another project that converts object storage buckets into mountable storage. geesefs has good performance and makes it easy to access the same bucket from the S3 API and the filesystem without obfuscating object names like juicefs. We have extended geesefs to leverage Tigris-specific features that improve throughput and latency. With tigrisfs you can use the S3 API or the filesystem interchangeably without having to worry about name mangling. tigrisfs is the canonical filesystem implementation for Tigris.
-Ovais Tariq, CEO @ Tigris Data

Your data: everywhere

Let’s imagine that you have big data in your stack. Not just big, but unimaginably big, we’re talking about data the size of Wikipedia, the entire Linux Kernel Mailing List archives, and the entire git history for all the big open source projects. Not to mention small datasets like every scientific paper from arxiv. tigrisfs lets you mount the same dataset in the same place on every machine in your cluster. Imagine just reading from /mnt/tigris/datasets/raw/lkml, processing the data around a bit, and then writing it to /mnt/tigris/datasets/massaged/lkml for the downstream analysis to run. We’ll go into more detail about this in the near future, keep an eye out for that!

The really cool part about this is that it lets you have a global filesystem on your local machine. All your data is just there and waiting to be used. If you write that massaged dataset to /mnt/tigris/datasets/massaged/lkml on one machine, it’s instantly available to any other machine in the cluster. Any time it’s used, it’ll be seamlessly cached on the device so that it’s hot’n’ready for action! It’s like having a ReadWriteMany Kubernetes volume, but without having to set up Ceph.

Dataset Type	Examples
Bigger than any one machine can hold with any number of disks	Wikipedia, Linux Kernel Mailing List archives, entire git history for all big open source projects, and every book published in the last 100 years
Bigger than any one disk	The entire YouTube upload history of your favorite creator
Smaller than RAM	Every scientific paper from arXiv

If you’re dealing with anything bigger than ram, tigrisfs is a great fit.

One of the neat parts about tigrisfs is that using it means you can deal with your files using either the S3 API or the filesystem API. This is in contrast to other tools like JuiceFS which break files into blocks and obfuscate the filenames, meaning you need to spend time and energy reverse-engineering how the block → data mapping works. With tigrisfs you can PUT an object into your bucket with the S3 API, and then open the file in your favorite text editor. This unlocks any number of fun integrations, including:

Using inotifywait to process data as it’s created in a bucket by your analytics pipeline
Backing up your home folder with rsync in a cronjob
Using tools like gzcat to read compressed data without having to decompress it
Storing TLS certificates across the cluster so that one machine can renew it, and it’ll roll out to the rest of the machines instantly
Reading your training datasets directly from disk instead of having to set up object storage with the datasets library
Reading a raw video out of one bucket and compressing it for global distribution into another bucket using ffmpeg

Let’s say you want to edit your secret plans in your Linux VM on your MacBook. First, upload it to Tigris with aws s3 cp:

$ aws s3 cp secretplans.txt s3://pitohui
upload: ./secretplans.txt to s3://pitohui/secretplans.txt

Then you can view it like normal with the shell:

xe@pitohui:~ $ cat /mnt/tigris/pitohui/secretplans.txt
- world domination via the use of hypnodrones
- make there be such a thing as a free lunch
- create more paperclips

And now you can do whatever you want! You can even do backups of your home folder with a single command:

xe@pitohui:~ $ rsync -av ~ /mnt/tigris/pitohui

The cloud’s the limit!

Getting started with tigrisfs

If you want to get started, all you need is an aarch64/x86_64 Linux system, a Tigris bucket, and a keypair.

Installing tigrisfs

One-liner install

This will install the latest version of tigrisfs and its dependencies.

curl -sSL https://raw.githubusercontent.com/tigrisdata/tigrisfs/refs/heads/main/install.sh | bash

Or, install using package manager

Download the package from the most recent release
Install the package using your package manager
- Debian/Ubuntu: sudo apt install ./tigrisfs-version.deb
- Alma Linux / Fedora / Red Hat / Rocky Linux: sudo dnf install ./tigrisfs-version.rpm

Mounting the filesystem

We are going to assume that you have a bucket called pitohui and you want to mount it to /mnt/tigris/pitohui.

Open /etc/default/tigrisfs in your favorite text editor as root and uncomment the AWS_ACCESS_KEY and AWS_SECRET_ACCESS_KEY variables and paste in the access key you got from the Tigris dashboard.

Using the command line

First, create the directory you want to mount the bucket to:

mkdir -p /mnt/tigris/pitohui

Then mount the bucket:

tigrisfs pitohui /mnt/tigris/pitohui

This gives me permission to do whatever I want such as touching grass:

$ touch /mnt/tigris/pitohui/grass
$ stat /mnt/tigris/pitohui/grass
  File: /mnt/tigris/pitohui/grass
  Size: 0               Blocks: 0       IO Block: 4096   regular empty file
Device: 80h/128d        Inode: 1631     Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/      xe)   Gid: ( 1000/     xe)
Context: system_u:object_r:fusefs_t:s0
Access: 2025-04-07 20:15:07.549222957 +0000
Modify: 2025-04-07 20:15:07.549222957 +0000
Change: 2025-04-07 20:15:07.549222957 +0000
 Birth: -

And make sure it exists in Tigris:

$ aws s3 ls s3://pitohui | grep grass
2025-04-07 16:15:07         0 grass

Perfect! If you are looking to crank up performance, there are a few configuration options that you can tweak. Take a look at the documentation for more details.

Using systemd

If you’re in an environment with systemd, mount your bucket with systemctl enable --now:

sudo systemctl enable --now tigrisfs@bucketname.service

Your bucket will be available at /mnt/tigris/bucketname. If you need things to be writable by your user account, edit the OPTS line based on your account’s information. For example on my MacBook’s Oracle Linux VM:

$ iduid=1000(xe) gid=1000(xe) groups=1000(xe),10(wheel) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

My user id (uid) is 1000 and my group id (gid) is 1000, so to give my user permissions, I need this OPTS line:

# Mount optionsOPTS="-o allow_other --gid=1000 --uid=1000"

This gives me permission to do whatever I want such as touching grass:

$ touch /mnt/tigris/pitohui/grass$ stat /mnt/tigris/pitohui/grass File: /mnt/tigris/pitohui/grass Size: 0 Blocks: 0 IO Block: 4096 regular empty fileDevice: 80h/128d Inode: 1631 Links: 1Access: (0644/-rw-r--r--) Uid: ( 1000/ xe) Gid: ( 1000/ xe)Context: system_u:object_r:fusefs_t:s0Access: 2025-04-07 20:15:07.549222957 +0000Modify: 2025-04-07 20:15:07.549222957 +0000Change: 2025-04-07 20:15:07.549222957 +0000 Birth: -

And make sure it exists in Tigris:

$ aws s3 ls s3://pitohui | grep grass2025-04-07 16:15:07 0 grass

Perfect! If you are looking to crank up performance, there are a few configuration options that you can tweak. Take a look at the documentation for more details.

Under the hood

tigrisfs is a fork of geesefs, a high performance FUSE filesystem adaptor for object storage. We have extended geesefs to leverage Tigris-specific features that improve throughput and latency.

tigrisfs is a high performance FUSE filesystem adaptor for object storage based on geesefs, which is a fork of goofys. GeeseFS solves performance problems which FUSE file systems based on S3 typically have, especially with small files and metadata operations. It solves these problems by using aggressive parallelism and asynchrony.

Improvements over GeeseFS

Our initial release zeroed-in on hardening the codebase for production, focusing on two areas:

Security hardening
- Replaced the bundled, legacy AWS SDK that contained known CVEs
- Upgraded every dependency to its latest secure version
Reliability upgrades
- Eliminated all race conditions flagged by the Go race detector (now mandatory in tests)
- Fixed every linter warning and added lint checks to CI
- Dramatically expanded the test-suite and made the extended tests a default part of CI

Tigris-specific improvements

We also shipped a few features that lean on Tigris internals:

POSIX semantics - permissions, special files, and symlinks now behave just like they do on a local disk.
Turbo-charged small files - listing a directory automatically batch-fetches and caches tiny objects in a single round-trip.
Smart prefetch - directory listings kick off background fetches so the next cat or grep feels instant.

In essence, tigrisfs bridges the gap between the Linux kernel and Tigris. It translates filesystem calls into S3 API calls so that you can explore your bucket with the shell and bridge the gap between the old world of servers and shells with the new world of dynamic infinity in the cloud.

Benchmarks

Benchmarking filesystems is kind of annoying, and networked filesystems can be even more annoying to benchmark. Most of the time, you end up making a lot of assumptions about the system state and network configuration. Here are the specs of our benchmarking machine:

Component	Quantity
Instance type	VM.Standard.E5.Flex (Oracle Cloud)
CPU cores	24
Memory	24 gigabytes (24Gi)
Network bandwidth	24 gigabits per second

Our benchmarks are done with the flexible i/o tester fio. Note that we are using direct I/O to avoid page cachingbeing an issue.

Read performance

Here is the command we used to test read performance on a bucket:

fio --name=read_throughput \
    --directory=/mnt/test-tigrisfs-bucket \
    --numjobs=4 \
    --size=4G \
    --time_based \
    --runtime=120s \
    --ramp_time=2s \
    --ioengine=libaio \
    --direct=1 \
    --verify=0 \
    --bs=1M \
    --iodepth=1 \
    --rw=read \
    --group_reporting=1

This has fio run for 2 minutes with 2 seconds of ramp-up time (during which, the results are not counted in the statistics) trying to read up to 4 gigabytes of data per thread (job) in one megabyte blocks. This reads a total of 16 gigabytes of data. The test was run in permutations of thread count and block size to see if the limitations are on tigrisfs, the Tigris service, and the network card of the machine.

And we got these results for each permutation of the test:

Threads	Block Size	Throughput (MiB/sec)
4	1M	1630
4	4M	2446
8	1M	2802 *
8	4M	2732 *

NOTE
The throughput numbers with the asterisk next to them could theoretically be faster, but at this point we saturated out the network card on the test machine.

Write performance

Here is the command we used to test write performance:

fio --name=write_throughput \
    --directory=/mnt/test-tigrisfs-bucket \
    --numjobs=8 \
    --size=4G \
    --time_based \
    --runtime=120s \
    --ramp_time=2s \
    --ioengine=libaio \
    --direct=1 \
    --verify=0 \
    --bs=4M \
    --iodepth=1 \
    --rw=write \
    --group_reporting=1

This has fio run for 2 minutes with 2 seconds of ramp-up time (during which the results are not counted in the statistics) trying to write up to 4 gigabytes of data per thread (job) in four-megabyte blocks. This writes a total of 16 gigabytes of data. The test was run in permutations of thread count and block size to see if the limitations are on tigrisfs, the Tigris service, and the network card of the machine.

And we got these results for each permutation of the test:

Threads	Block Size	Throughput (MiB/sec)
4	1M	1118
4	4M	1119
8	1M	1269
8	4M	1279

Needless to say, this represents being able to read and write multiple DVDs of data per second per machine with tigrisfs. This combined with the caching that tigrisfs uses means that it should be more than sufficient for anything you can throw at it.

When should I use tigrisfs?

Feature	TigrisFS	S3 API
Legacy Tool Integration	✅	❌
Direct Filesystem Access	✅	❌
On-Demand File Fetching	✅	❌
AI Model Training	✅	✅
Global Performance	✅	✅

Personally, I use tigrisfs all the time on my own machines. One of the main things I use it for is running analytics across honeypot logs so that I can fight off evil scrapers and save the internet.

In general, tigrisfs can be slower than the native disk for files that aren't cached yet, but it more than makes up for it by allowing you to make the location of your files irrelevant. All you need to do is run tigrisfs, and you have a single global namespace for your data across all your machines.

tigrisfs is written in Go and is open source on GitHub. We welcome any and all contributions to make it even better!

This article was originally published on July 1, 2025 at tigrisdata.com/blog

Data Time Travel with DuckLake and Tigris

Shared Account — Wed, 25 Jun 2025 00:00:00 +0000

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?

If you’re using most database engines, this is a priority zero “stop the world and restore from backups” shaped problem. This is especially annoying with analytics databases because many times those databases aren’t just bigger than ram, they’re bigger than your local disk, and sometimes even bigger than any disk in any computer can ever be. But further, if your AI starts renaming columns or combining data in interesting ways, it can be quite the mess to untangle, even impossible. In such cases, this is an XK-class end-of-the-project scenario, which is triple-plus ungood.

However, you read our last post on DuckLake and have been storing your analytics data in Tigris so you can get that sweet, sweet global performance. How do you go back to the past where everything Just Worked? Turns out it’s easy, no DeLorean required. All you have to do is reset the timeline with a couple simple commands.

DuckLake and you

DuckLake is an analytics data lakehouse that lets you import SQL and NoSQL data so you can run SQL queries on it. One of the really cool parts about DuckLake is that when you do any INSERT or DELETE into DuckLake tables, you create a new snapshot of the database that you can roll back to. DuckLake turns your SQL database into an append-only-log.

As an example, let’s create a DuckLake database backed by Tigris, insert some data and see what happens. First, install DuckDB and then set up the DuckLake extension:

INSTALL ducklake;LOAD ducklake;

Then attach to a new DuckLake database in Tigris:

ATTACH 'ducklake:timetravel_demo.ddb'AS delorean ( DATA_PATH 's3://xe-ducklake/delorean' );

Note: This creates the DuckLake metadata on the local filesystem which is fine for demos like this, but for production use we suggest putting your DuckLake metadata in the cloud with a Postgres database or one of the other backends DuckLake supports.

Now that we have the database, let’s create a simple table and throw some data in it:

CREATE TABLE IF NOT EXISTS delorean.youtube_videos ( id TEXT NOT NULL PRIMARY KEY , title TEXT NOT NULL , channel TEXT NOT NULL );INSERT INTO delorean.youtube_videos ( id, title, channel )VALUES ( 'WcSCYzI2peM', 'Delfino Plaza (Super Mario Sunshine) - Mario Kart World', 'SiIvaGunner' ), ( 'W4AcveHnDzg', 'Retribution for the Eternal Night ~ Imperishable Night (Beta Mix) - Touhou 8: Imperishable Night', 'SiIvaGunner' );

Awesome, let’s see what the bucket looks like:

$ aws s3 ls s3://xe-ducklake/delorean/main/youtube_videos/2025-06-25 10:28:34 1175 ducklake-0197a77d-905b-7624-8e32-c80c69470e52.parquet

Interesting, DuckLake created a parquet file named after the table we inserted the data into, let’s see what it looks like:

FROM 's3://xe-ducklake/delorean/main/youtube_videos/ducklake-0197a77d-905b-7624-8e32-c80c69470e52.parquet';

id	title	channel
WcSCYzI2peM	Delfino Plaza (Super Mario Sunshine) - Mario Kart World	SiIvaGunner
W4AcveHnDzg	Retribution for the Eternal Night ~ Imperishable Night (Beta Mix) - Touhou 8: Imperishable Night	SiIvaGunner

This is the key to how DuckLake works. Every time you write to one of its tables, it puts those rows you added into a parquet file in object storage. Let’s see the changes we made to the delorean database:

FROM ducklake_snapshots('delorean');

snapshot_id	snapshot_time	schema_version	changes
0	2025-06-25 10:19:32.897-04	0	`{schemas_created=[main]}`
1	2025-06-25 10:27:33.45-04	1	`{tables_created=[main.youtube_videos]}`
2	2025-06-25 10:27:40.828-04	2	`{tables_dropped=[1]}`
3	2025-06-25 10:27:45.229-04	3	`{tables_created=[main.youtube_videos]}`
4	2025-06-25 10:28:33.497-04	3	`{tables_inserted_into=[2]}`

The first change is creating the main schema, and then you can see that while I was working on this article I made the youtube_videos table, messed up the schema, dropped it, recreated it, and then inserted information about epic tunes into the table. To really show off this time travel power though, let’s delete the data and then add other data into the mix:

DELETE FROM delorean.youtube_videos;INSERT INTO delorean.youtube_videos ( id, title, channel )VALUES ( 'jhl5afLEKdo', 'Hatsune Miku World is Mine / ryo（supercell)', 'Hatsune Miku' ), ( 'sqK-jh4TDXo', 'Machine Love (feat. Kasane Teto)', 'Jamie Page' );

So what happened to the database? Here’s what the table looks like now:

SELECT * FROM delorean.youtube_videos;

id	title	channel
jhl5afLEKdo	Hatsune Miku World is Mine / ryo（supercell)	Hatsune Miku
sqK-jh4TDXo	Machine Love (feat. Kasane Teto)	Jamie Page

But if you look in the bucket, the old data is still there:

FROM 's3://xe-ducklake/delorean/main/youtube_videos/*.parquet';

id	title	channel
WcSCYzI2peM	Delfino Plaza (Super Mario Sunshine) - Mario Kart World	SiIvaGunner
W4AcveHnDzg	Retribution for the Eternal Night ~ Imperishable Night (Beta Mix) - Touhou 8: Imperishable Night	SiIvaGunner
jhl5afLEKdo	Hatsune Miku World is Mine / ryo（supercell)	Hatsune Miku
sqK-jh4TDXo	Machine Love (feat. Kasane Teto)	Jamie Page

How do you get the old data back? Well for one, we can time travel directly in SQL queries! Let’s look at the database snapshots again and try to figure out what happened:

FROM ducklake_snapshots('delorean');

snapshot_id	snapshot_time	schema_version	changes
4	2025-06-25 10:28:33.497-04	3	`{tables_inserted_into=[2]}`
5	2025-06-25 10:38:19.959-04	3	`{tables_deleted_from=[2]}`
6	2025-06-25 10:41:48.455-04	3	`{tables_inserted_into=[2]}`

So it looks like the table was added to in snapshot 4, the data was deleted in snapshot 5, and the new data comes in at snapshot 6. Let’s get the superset of the data at snapshot 4 AND snapshot 6:

SELECT * FROM delorean.youtube_videos AT (VERSION => 4)UNION ALLSELECT * FROM delorean.youtube_videos AT (VERSION => 6)

id	title	channel
WcSCYzI2peM	Delfino Plaza (Super Mario Sunshine) - Mario Kart World	SiIvaGunner
W4AcveHnDzg	Retribution for the Eternal Night ~ Imperishable Night (Beta Mix) - Touhou 8: Imperishable Night	SiIvaGunner
jhl5afLEKdo	Hatsune Miku World is Mine / ryo（supercell)	Hatsune Miku
sqK-jh4TDXo	Machine Love (feat. Kasane Teto)	Jamie Page

You can see the power here right? The data is still safely stored in your bucket, so deletes don’t matter. It may be more inconvenient to access the data, but you can also time travel for the entire database at once:

ATTACH 'ducklake:timetravel_demo.ddb'AS delorean_past ( DATA_PATH 's3://xe-ducklake/delorean' , SNAPSHOT_VERSION 4 );SELECT * FROM delorean_past.youtube_videos;

id	title	channel
WcSCYzI2peM	Delfino Plaza (Super Mario Sunshine) - Mario Kart World	SiIvaGunner
W4AcveHnDzg	Retribution for the Eternal Night ~ Imperishable Night (Beta Mix) - Touhou 8: Imperishable Night	SiIvaGunner

Advanced temporal mechanics

You’re not limited to just running queries against the past, you can also connect to the database at a given point in time. This combined with making a local fork of the database lets you get into advanced temporal mechanics.

Let’s make a local copy of the database to debug the AI agent’s changes. Connect to the database in the past before the AI model messed things up:

ATTACH 'ducklake:timetravel_demo.ddb'AS delorean_past ( DATA_PATH 's3://xe-ducklake/delorean' , SNAPSHOT_VERSION 4 );

Cool, then let’s make a local copy of it at that point in time:

ATTACH 'ducklake:timetravel_local_copy.ddb'AS local_delorean ( DATA_PATH 's3://xe-ducklake/delorean' );COPY FROM DATABASE delorean TO local_delorean;DETACH delorean;DETACH local_delorean;

The magic part of that is the COPY FROM DATABASE instruction. That makes a copy of the database locally so you can debug the AI agent’s change and prevent a future timeline from coming to pass the way the current one did. Then for the cherry on top, attach the local database with the same name as the remote one so that your agent is none the wiser:

ATTACH 'ducklake:timetravel_local_copy.ddb'AS delorean ( DATA_PATH 's3://xe-ducklake/delorean' );

Et voila! We have successfully forked the timeline and can now make any change we want without affecting the main timeline. Test it by running a SQL query:

SELECT * FROM delorean.youtube_videos

id	title	channel
WcSCYzI2peM	Delfino Plaza (Super Mario Sunshine) - Mario Kart World	SiIvaGunner
W4AcveHnDzg	Retribution for the Eternal Night ~ Imperishable Night (Beta Mix) - Touhou 8: Imperishable Night	SiIvaGunner

The really cool part is that we did all that without affecting the data in Tigris:

SELECT * FROM 's3://xe-ducklake/delorean/main/youtube_videos/*.parquet';

id	title	channel
WcSCYzI2peM	Delfino Plaza (Super Mario Sunshine) - Mario Kart World	SiIvaGunner
W4AcveHnDzg	Retribution for the Eternal Night ~ Imperishable Night (Beta Mix) - Touhou 8: Imperishable Night	SiIvaGunner
jhl5afLEKdo	Hatsune Miku World is Mine / ryo（supercell)	Hatsune Miku
sqK-jh4TDXo	Machine Love (feat. Kasane Teto)	Jamie Page

When we made a copy of the data lake to hack on locally, all we were copying was the schemata of the database and references to objects in Tigris. At some level, the tables don’t logically exist, they’re really just a bunch of rules and references that DuckLake uses to rebuild your database on the fly! And because the tables quack like SQL tables enough, the illusion is maintained!

Another really cool thing is that every INSERT or UPDATE operation results in discrete parquet files being put into Tigris:

$ aws s3 ls s3://xe-ducklake/delorean/main/youtube_videos/2025-06-25 10:28:34 1175 ducklake-0197a77d-905b-7624-8e32-c80c69470e52.parquet2025-06-25 10:41:49 975 ducklake-0197a789-b1b2-797e-8bd5-a20905d2d73f.parquet

These parquet files are written to once and NEVER updated. This means that as your analytics pipelines or developers all over the world access things, they’re automatically fast and local thanks to Tigris’ global performance.

Victory achieved!

Now you can turn your analytics pipeline back on and go on with hacking up a storm. Next time you do those changes with your AI agent though, make sure to test them against a backup of the data lake just in case things go pear-shaped again. Ensure your AI isn’t renaming columns, deleting tables, changing the structure, etc. Ideally your schema changes should only add columns and never remove them. Your database tables should be treated as a public API.

To make a local backup of your data lake so your agent can break whatever the tokens deem worthy without breaking prod:

ATTACH 'ducklake:timetravel_local_copy.ddb'AS local_delorean ( DATA_PATH 's3://xe-ducklake/delorean' );COPY FROM DATABASE delorean TO local_delorean;DETACH delorean;DETACH local_delorean;ATTACH 'ducklake:timetravel_local_copy.ddb'AS delorean ( DATA_PATH 's3://xe-ducklake/delorean' );

And to attach to DuckLake in read-only mode so that it can’t break anything if it wanted to:

ATTACH 'ducklake:timetravel_demo.ddb'AS stone_tablet ( DATA_PATH 's3://xe-ducklake/delorean' , READ_ONLY -- <- attaches the ducklake database in read-only mode );

And then you can go back to fearless vibe coding to make your dreams come true in the form of B2B SaaS! All your data will be safe in the cloud and fast to load anywhere in the world, even if you need to time travel a bit to get things working again.

Analytics databases with time travel!

Tigris lets you store your data everywhere, including your analytics data. When you use Tigris and DuckLake together, you get global performance to rival the cloud giants at a fraction of the cost. Query data from the past to bring you to a better future!

This article was originally published on June 25, 2025 at tigrisdata.com/blog

Announcing the Tigris MCP server

Shared Account — Tue, 24 Jun 2025 22:12:33 +0000

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

A robotic blue tiger using tools to work on an engine.

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.

Abdullah just started at Tigris a week ago (Welcome!) and has already built
something that will make it easier for you to make object storage a native part
of your development workflow: a Model Context Protocol (MCP) server for Tigris.
This enables you to manage your buckets and objects with plain language in your AI capable editor.

Just say “make me a bucket for this project” and it’ll go do that. Want files in the bucket? Just ask it to upload a file; it’ll make it happen.

The vision

We want your developer experience with Tigris to be as seamless, unsurprising,
and natural as possible. What’s more natural than natural language? Getting this
set up was a breeze. Tigris is compatible with S3, so all Abdullah had to do was
glue S3 calls to the MCP library. Everything was already there, well-tested, and
ready to go. And it’s just object storage: there’s no chance you’ll accidentally
spin up an expensive service and get a surprise bill.

Of note: many other MCP servers will try and do much more than they need to. Our
MCP server just does object storage. There’s no possibility of it spinning up
expensive servers and saddling you with a surprise bill with an unreasonable
number of zeroes in it.

Getting started

To get started, create some access keys and then install our MCP server:

Edit your config file

Add this snippet to your claude_desktop_config.json or mcp.json for Cursor
AI

{
  "mcpServers": {
    "tigris-mcp-server": {
      "command": "npx",
      "args": ["-y", "@tigrisdata/tigris-mcp-server", "run"],
      "env": {
        "AWS_ACCESS_KEY_ID": "YOUR_AWS_ACCESS_KEY_ID",
        "AWS_SECRET_ACCESS_KEY": "YOUR_AWS_SECRET_ACCESS_KEY",
        "AWS_ENDPOINT_URL_S3": "https://fly.storage.tigris.dev"
      }
    }
  }
}

Run the init script

Run the init script in your terminal:

npx -y @tigrisdata/tigris-mcp-server init

Then ask your editor to make you a bucket for a project and it will! More instructions are on the official npm package here.

Trust

AI editors and tooling are really cool, but there’s some key things you should
be aware of before you blindly trust this. The Model Context Protocol ecosystem
is still very new, so there will almost certainly be problems we solve together
over time. There are also inherent risks involved in giving any tool access to
your cloud storage accounts or filesystem.

The Model Context Protocol server will run in the same level of sandboxing as your editor does. Be careful with what you install and always double-check what you run before you run it.

In order to make this as safe as possible, we’ve made the Model Context Protocol
also available as a docker container. This means you can run it in a sandboxed
environment and not have to worry about it having access to your local
filesystem. You can run it in a container and container have access to a
specific directory on your local filesystem. This is a great way to make sure
that the Model Context Protocol server can only access the files you want it to.

Edit your config file

Add this snippet to your claude_desktop_config.json or mcp.json for Cursor
AI. Please note that CURRENT_USER references the user running the command.

{
  "mcpServers": {
    "tigris-mcp-server": {
      "command": "docker",
      "args": [
        "run",
        "-e",
        "AWS_ACCESS_KEY_ID",
        "-e",
        "AWS_SECRET_ACCESS_KEY",
        "-e",
        "AWS_ENDPOINT_URL_S3",
        "--network",
        "host",
        "--name",
        "tigris-mcp-server-claude-for-desktop", // tigris-mcp-server-cursor for Cursor AI
        "-i",
        "-v",
        "tigris-mcp-server:/app/dist",
        "--rm",
        "--mount",
        "type=bind,src=/Users/CURRENT_USER/tigris-mcp-server,dst=/Users/CURRENT_USER/tigris-mcp-server",
        "quay.io/tigrisdata/tigris-mcp-server:latest"
      ],
      "env": {
        "AWS_ACCESS_KEY_ID": "YOUR_AWS_ACCESS_KEY_ID",
        "AWS_SECRET_ACCESS_KEY": "YOUR_AWS_SECRET_ACCESS_KEY",
        "AWS_ENDPOINT_URL_S3": "https://fly.storage.tigris.dev"
      }
    }
  }
}

Run the init script

Run the init script in your terminal and select Docker as option when
prompted

npx -y @tigrisdata/tigris-mcp-server init

This Model Context Protocol server will run with the full power and authority of any credentials you give it. Be very careful about typos with object names that have similar token distances.

Additionally, AI tools are fundamentally built around random behavior and will
have unexpected results at times. Sometimes it takes the AI a couple tries to
learn what you want to do. Be very careful, as typos in an AI context can have
much more drastic consequences than they can in normal contexts. We don’t want
you to lose data you need. For example, when you run the DeleteBucket call,
you are not allowed to do this unless the bucket has no data in it.

In order to be as transparent as possible, we’ve made our Model Context Protocol server open source and are actively monitoring that repository.

We’re making this as safe and reliable as possible. Part of this is the scope
reduction we mentioned earlier: we’re only managing your buckets and objects. The other part is by going out of our way to make this tool as boring as possible. Boring code is easy to understand, easy to maintain, and easy to learn from. We hope that this will help you make the exciting parts of your program while leaving the boilerplate to machines.

We hope this will make using Tigris absolutely frictionless and that you can
learn how S3’s API works in the process. Not to mention, we want you to get out
there and build things!

This article was originally published on April 3, 2025 at tigrisdata.com/blog

Global by Design: Tigris's Distributed Object Storage Architecture

Shared Account — Tue, 24 Jun 2025 22:00:01 +0000

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?

Storage devices can and will degrade over time. Your CPUs aren't immune from it either, recent Intel desktop CPUs have been known to start degrading and returning spontaneous errors in code that should work. Your datacenters could be hit by a meteor or a pipe could burst: being in the cloud doesn't mean perfect reliability. But failovers and multiple writes take precious time. We write your data to 11 regions based on access patterns, so you get low latency (and therefore higher user retention), without sacrificing reliability.

Here's how Tigris globally replicates your data; but first, let's cover the easy and hard problems of object storage.

Object storage 101

At its core, object storage is an unopinionated database. You give it data, metadata, and a key name, then it stores it. When you want the data or metadata back, you give the key and it gives you what you want. This is really the gist of it, and you can summarize most of the uses of object storage in these calls:

PutObject - add a new object to a bucket
GetObject - get the data and metadata for an object in a bucket
HeadObject - get the metadata for an object in that bucket
DeleteObject - banish an object to the shadow realm, removing it from the bucket
ListObjectsV2 - list the metadata of a bunch of objects in a bucket based on the key

This is the core of how object storage is used. The real fun comes in when you create a bucket. A bucket is the place where all your objects are stored. It's kind of like putting a bunch of shells in a bucket when you're at the beach.

Most object storage systems make you choose up front where in the world you want to store your objects. They have regions all over the world, but if you create a bucket in us-east-1, the data lives and dies in us-east-1. Sure, there's ways to work around this like bucket replication, but then you have to pay for storing multiple copies, and wait for cross region replication to get around to copying your object over. Tigris takes a different approach: your objects are dynamically placed by default.

Tigris has servers all over the world. Each of those regions might have any given object, and they might not (unless you restrict the regions to comply with laws like GDPR). What happens when you request an object that doesn't exist locally?

How Tigris does global replication

Tigris takes a different approach here. Tigris uses a hybrid of pushing metadata out to every region, but only pulling the data when it's explicitly requested. We use FoundationDB as our database.

In Tigris we have three tiers:

SSD Cache: Near instant responses for either data+metadata or just the metadata FoundationDB: Fast but transactional responses for data+metadata if the object is inlined to the FoundationDB record, otherwise just the metadata
Block storage: More latent responses for objects that are not in the SSD cache
Overall it looks kinda like this:

Let's see what happens when a user uploads a file to a bucket:

The user uploads the picture of Rick Astely and its corresponding metadata. These two are separately handled. The picture is put into block storage (and maybe the SSD cache), but the metadata is stored directly in FoundationDB. Then the metadata is queued for replication.

A backend service handles our replication model. When it sees a new record in the replication queue, it eagerly pushes out the metadata to every other region.

The really cool part about how this works under the hood is that the database is itself the message queue. Time as an ordered phenomenon*. FoundationDB is an ordered datastore. The replication queue entries use the time that the object was created in its key name.

NOTE
*Okay yes there's issues like time dilation when you're away from a large source of mass like the earth (this is noticeable in the atomic clocks that run GPS in low earth orbit), and if you're on a spaceship that's near the speed of light. However, I'm talking about time in a vacuum with a nearby source of great mass, perfectly spherical cows, and whatnot, so it's really not an issue for this example.

This database-as-a-queue is based on how iCloud's global replication works. It gives us a couple key advantages compared to using something like postgres and kafka:

Data can be stored and queued for replication in the same transaction, meaning that we don't have to coordinate transactional successes and failures between two systems
Tigris is already an expert in running FoundationDB, so we can take advantage of that experience and share it with our message queue, making this a lot less complicated in practice.

This isn't a free lunch, there's one sharp edge that you may run into: that replication takes a nonzero amount of time. It usually takes single digit seconds at most, which is more than sufficient for most applications. We're working on ways to do better though!

The secret fourth tier

Remember how I said that Tigris has three tiers: block storage, SSD cache, and inline FoundationDB rows? There's actually a secret fourth tier: other Tigris regions. This is the key to how Tigris makes your data truly global.

Let's say you upload the pic of Rick to San Jose and someone requests it from Chicago. First, the data is put into San Jose's block storage layer and the metadata is queued for replication.

There's a dirty trick going on in the metadata, let's double click on it:

# Metadata:

Name: rickastley.jpg
Size: 63,178 bytes
Cache: forever
Regions: SJC

Every bit of metadata contains a reference to block storage. The cool part is that any Tigris region can pull from the block storage service in every other region. Then it stores it inside the cache layer like normal.

Once it's done, it updates the metadata for the object to tell other Tigris regions that it has a copy and queues that for replication:

# Metadata:

Name: rickastley.jpg
Size: 63,178 bytes
Cache: forever
Regions: SJC, ORD

This means that there's actually four tiers: FoundationDB, SSD cache, local block storage, and remote region's block storage.

There's also a neat trick we can do with this. We can have one of our regions get hit by a meteor and come out on the other side of it smiling. Take a look at this series of unfortunate events. Let's say you upload the pic of Rick and then SJC gets wiped off the internet map:

The metadata was already replicated and the data was uploaded to block storage, so it doesn't matter.

The user in Chicago can still access the picture because the Chicago region is just accessing the copy of the image in block storage. The block storage service runs in the same region as the Tigris frontend, but specifically on a different provider. This combined with other dirty internet tricks like anycast routing means that we can suffer losing entire regions and the only proof that it's happening is either our status page or you might notice that uploads and downloads are a tiny bit slower until the regions come back up.

This is what sold me on Tigris enough to want to work with them. This ridiculous level of redundancy, global replication, and caching is the key to how Tigris really makes itself stand apart from the crowd. What I think is the best part though is that here's how you enable all of this:

All you have to do is create a bucket and put objects into it. This global replication is on by default. You don't have to turn it on. It just works.

What's Configurable?

What about the GDPR? Some European countries want their companies to store European data in Europe. We support that. When you create a bucket, you can attach an X-Tigris-Regions header that restricts the objects so that the data lives and dies in Europe. You can do this when you create objects too. See restricting to specific regions for more information. When someone outside of the EU views the objects, Tigris will just reverse proxy it over. It'll be slower, but the data will not be replicated outside of the EU. This works for individual regions too, just in case you need your hockey game pictures to only ever be stored in Newark.

Sometimes you need eager caching on PUT. We support that with the accelerate flag. When you upload a picture to ORD, it'll get pushed out all over the world for you:

This gives you all the latency advantages of having a traditional centralized architecture as well as the simplicity of a decentralized architecture. It's really the best of both worlds.

Wanna use Tigris for your workloads, be they AI, conventional, or even for offsite backups? Get started today at storage.new.

This article was originally published on April 1, 2025 at tigrisdata.com/blog

DEV Community: Shared Account

gpt-oss is not for developers. It’s for agents.

What are the Tradeoffs?​

What’s hiding in the model card?​

Tool use​

Safety First​

The technology of safety​

The Harmony Response Format​

Yap-time tool use​

Monitoring reasoning for unsafe outputs before they happen​

Reasoning is built in​

My agentic experience with gpt-oss 120b​

Choose your models wisely​

Generative Software Development: From Coding to Conversing

From Autocomplete to AI Partners​

The Four Generations of Developer Assistance​

1996–2021

IntelliSense Era

2021–2024

AI Revolution (Copilot)

2024–2025

AI-Native IDEs (Cursor)

2025–Present

Prompt-Based Development (Claude Code or GPT-5 via Codex CLI)

The Turning Point: GitHub Copilot​

Cursor: The IDE Redefined​

Claude Code: The Prompt Revolution​

The Future: From Coding to Conversing​

I Tested Qwen Image's Text Rendering Claims. Here's What I Found.

Introduction​

How diffusion models work​

Qwen Image claims to have solved complex text rendering​

Multi-line layouts​

Paragraph-level semantics​

Fine-grained details​

So how does Qwen Image Stack up?​

Conclusion​

Store your models on Tigris

Using Hugging Face datasets with Tigris

Prerequisites​

Setting up your environment manually

Importing a dataset​

Reading and processing datasets from Tigris​

Conclusion​

We made unhateable IAM. Here’s how to use it.

Example: Running a Training Job on a Newer Cloud Provider​

Burying the Lede: Linked Access Keys​

Conclusion​

Getting started with Warpstream on Tigris

Prerequisites​

Building a compose file​

Small Objects, Big Gains: Benchmarking Tigris Against AWS S3 and Cloudflare R2

Summary​

Benchmark Setup​

YCSB Configuration​

Results

Loading 10 million objects​

1 million operations (20% write, 80% read)​

Read throughput​

Read latency​

Write throughput​

Write latency​

Conclusion​

Standardizing Python Environments with Development Containers

How it works​

What about Python?​

Conclusion​

mount -t tigrisfs

Your data: everywhere

Getting started with tigrisfs​

Installing tigrisfs

Mounting the filesystem

Using the command line

Using systemd

Under the hood​

Improvements over GeeseFS

Tigris-specific improvements

Benchmarks​

Read performance​

Write performance​

What are the Tradeoffs?

What’s hiding in the model card?

Tool use

Safety First

The technology of safety

The Harmony Response Format

Yap-time tool use

Monitoring reasoning for unsafe outputs before they happen

Reasoning is built in

My agentic experience with gpt-oss 120b

Choose your models wisely

From Autocomplete to AI Partners

The Four Generations of Developer Assistance

The Turning Point: GitHub Copilot

Cursor: The IDE Redefined

Claude Code: The Prompt Revolution

The Future: From Coding to Conversing

Introduction

How diffusion models work

Qwen Image claims to have solved complex text rendering

Multi-line layouts

Paragraph-level semantics

Fine-grained details

So how does Qwen Image Stack up?

Conclusion

Prerequisites

Importing a dataset

Reading and processing datasets from Tigris

Conclusion

Example: Running a Training Job on a Newer Cloud Provider

Burying the Lede: Linked Access Keys

Conclusion

Prerequisites

Building a compose file

Summary

Benchmark Setup

YCSB Configuration

Loading 10 million objects

1 million operations (20% write, 80% read)

Read throughput

Read latency

Write throughput

Write latency

Conclusion

How it works

What about Python?

Conclusion

Getting started with tigrisfs

Under the hood

Benchmarks

Read performance

Write performance

When should I use tigrisfs?

DuckLake and you

Advanced temporal mechanics

Victory achieved!