Hi Tigris,
I just read your Series A article on the Tigris blog, congrats. But what does it mean for your collaboration with Fly? Currently, billing and logins flow through Fly.io, but I can imagine that this is about to change when you run on your own hardware. Could you eleborate on this a bit?
Thanks!
Hi @hakoptak
As you have read in our Series A article, with the fundraise we are investing in growing our infrastructure footprint so we can serve our users better. We continue to partner with Fly.io and there are no changes in our partnership with Fly.io whatsoever. But at the same time we have also built out our own infrastructure running on our own hardware for users that use Tigris outside of Fly.io.
Our storage endpoint t3.storage.dev is hosted on our own hardware. For example, you can see the different regions listed here: Regions | Tigris Object Storage Documentation
I would be happy to answer any further questions about this.
Best,
Ovais
Hi @ovaistariq, thanks for your clarification. Now it makes more sense why there are two storage endpoints… I clearly missed this connection. Except for the supported regions, do both endpoints have comparible characteristics regarding network and storage latency?
If your app is hosted within fly.io, you will of course get better latency from our fly specific endpoint. But if you are hosted outside of fly.io, then we recommend using the t3 endpoint.
Hi @ovaistariq,
Thanks for your quick response!
One last question: do you plan to support the same fly.io regions for the t3.storage.dev endpoint? It would be nice to see equal coverage (but I don’t need it right away). Also, this would make the choice for t3.storage.dev easier.
I really like the progress you’re making and Tigris is definitely the best S3-compatible solution out there. I hope to roll out my edtech tool soon and rely on Tigris to create value.
Hi @hakoptak,
We do plan on supporting more regions, may be not all of the same fly.io regions. But at least have the Singapore / or Japan region available soon on the t3 endpoint.
That’s great news. Ideally you would want to cover all continents to have the lowest latency, but I’ll find a Vultr instance near any of the chosen regions. Good luck with going forward.
Thanks.
Does this mean that fly.io users using the fly endpoint will never be serviced by your own hardware?
We have an alternate endpoint t3.storage.dev that is serviced by our own hardware. Is that what you are asking?
To clarify, I was asking if the fly.storage.tigris.dev endpoint utilizes your own hardware as well
Yes, some parts of our stack always run on our own hardware, so fly.storage.tigris.dev does utilize our hardware for some parts of the system that way.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.