Clarify data transfer pricing

Hi there,

I am evaluating Tigris against Bunny (CDN + Storage). Compared to Bunny, Tigris gives more control to select regions and when life cycles are implemented I would definitely see it as a viable option.

For my use case the costs are very similar, provided that Tigris’ egress is free. But the latter is not guaranteed. From the website:

Egress in the majority of use cases. However, if your bandwidth requirements are extraordinary, please reach out to us.

It would help to get real numbers here. For example: the first 10 Tb is free, then X per Tb.

Currently, I cannot make a business case because my use case is heavy on bendwidth, not on storage. Could you eleborate on this? Thanks in advance.


Thank you so much for evaluating Tigris and considering it for your use case!

I had a feeling this question would come up eventually :slight_smile:

For the majority of our users, data egress is completely free. We aim to keep our pricing transparent and supportive of typical usage patterns without any extra costs. However, we don’t have a standardized pricing model yet for extraordinary bandwidth requirements.

We’re currently working on figuring out the best way to structure charges for these exceptional cases. One idea we’re exploring is around bandwidth QoS (Quality of Service). I’d love to hear your thoughts on this approach.

If you could share your specific bandwidth needs or projections, I’d be happy to dive into more details and work toward a solution that fits your business case.

First of all: thanks for your quick response.

Let me provide some context: I am building a realtime teaching tool where teachers share files (currently up to 25 Mb) and screenshots (about 1 Mb). It does a lot more but this is sufficient for now. A teacher is connected to between 50 and 300 students. This means that I have two use cases in one:

Use case 1: A burst of up to 300 simultaneous small downloads (screenshots)
Use case 2: A burst of up to 300 simultaneaus larger dowloads (files)

Use case 1 (smaller files) occurs more often per session, mainly because the sharing of files is limited. By the way: I use presigned urls in both cases for uploading and downloading, and these are shared via a websocket server.

When I compute the costs based on payment per mutation (Tigris, but also Cloudflare R2) and payment for bandwidth (Bunny) it happens that for this particular use case the costs are on par. However, if egress costs are included for Tigris then the balance tips over. So that’s why I want to know the specifics. It would be desirable to have these numbers on the pricing page.

Because of the realtime nature of my product I am interested in a Quality of Service approach, but mainly for throughput and latency. Currently it is hard to compare different vendors because these numbers are not disclosed. The only thing one can do is try out different services, measure the numbers and then make a decision. So it would be refreshing to see such an alternative appear on the market.

To be honest: My product is still very early but it would be great to think along with you.

You could use NATS object store for this use case.

when you add an image NATS wil ensure it gets to all the other NATS Leaf Nodes no matter where they are out in the world.

If the Users are on Desktop and Mobile it will just work. For Web, it can also work with

This is just an Idea. It is really really dependent on the same of your Project though.

There is a full example project here doing exactly this:

Thanks for thinking along, but I have already setup my messaging system… I’m not that early :wink: The last piece of the puzzle is to find a suitable multi-region, scalable storage solution. I host the messaging system myself but I don’t want to host the storage system.

Thank you for the detailed context and for sharing more about your real-time teaching tool. It sounds like an exciting and impactful project!

I understand the importance of keeping costs predictable, especially with the bursty nature of the downloads. But, given the nature of your use case, it seems the overall bandwidth requirement will not be excessively high. The screenshots and files will likely be compressed, and not all students will download the files simultaneously. Additionally, students will probably save the files locally after downloading, reducing repeated requests for the same file.

Regarding the Quality of Service (QoS) approach, we are still early in formalizing it which is why we don’t yet have this model up on our pricing page. Our current thinking is to provide everyone with a fixed throughput with support for bursts. This way, everyone will have a fair share of the overall bandwidth and predictable performance.

Being a teacher and building a product for teachers definitely gives me an unfair advantage. So yeah, I do think it is going to make an impact :grinning:

Good to hear that my usage pattern doesn’t trigger red flags or overages. You are correct that students won’t download files all at once, but this does happen with the screenshots. The student apps automatically download the screenshot to display it on the students’ screen. So my system will cause spikes of 300 simultaneous downloads. But if I understand correctly, the worst thing that can happen is that my bandwidth will be throttled. If it’s capped around 150 megabytes per second than I can guarantee a near realtime experience.

Thanks for your clarifications and for your time. I will keep an eye on Tigris as it matures during the following months and will generate some API keys to try it out “in the wild”.


I am glad we agree that it is going to make an impact :grinning:

You are right that the only thing you might see is bandwidth being throttled, which, as I mentioned earlier, given your use case it won’t affect you. I think this is a better approach that allows for your costs to be in control in contrast to the approach taken generally by other providers.

Lastly, I would say that Tigris is already quite mature and I would love for you to give it a go :slightly_smiling_face:

I will definitely try your service. It is indeed quite mature but I was referring to the absence of life cycle configuration. That would make my data management a bit easier.

Thanks again for your time and good luck with scaling up.


We are pretty close to having the lifecycle feature available. I will let you know.

And thank you for the discussion here, I really appreciate it.


This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.