Tigris
Globally-distributed object storage and database. S3-compatible, no egress fees.
VISIT TIGRISKey takeaway: Look at Tigris when transfer charges have become a real line item, because S3-compatible storage without egress fees changes the arithmetic for anything serving a lot of bytes. Treat it as storage infrastructure rather than as a database; for a relational or document brief, it is not the answer.
Quick facts
- CategoryKV / Redis / object
- EngineJS-native
- PricingFreemium
- LicenseProprietary
- Created2021
- GitHub stars0.5k
- PostgresNo
- Edge-readyYes
Bundled features: S3-compatible storage Global replication
What it is
Tigris is globally-distributed object storage with S3 compatibility plus a database layer. Built on FoundationDB, replicated across regions, no egress fees. Good fit for apps that need object storage near users without S3 egress costs.
Best for
- Apps moving away from S3 to escape egress costs
- Globally-distributed object storage workloads
- Multi-region deployments with low-latency object access
When not to pick it
Skip Tigris for relational data, its sweet spot is object storage. Skip if you only need single-region storage; the multi-region story is the differentiator.
My take
Niche but well-built. The "no egress" story is genuine and matters for high-bandwidth apps. For most database briefs, Tigris is not the answer.
S3 compatibility means the migration is mostly a config change
The most useful thing about Tigris is that it speaks the S3 API. Your existing SDK calls, your upload pipeline, and most of your tooling keep working against a different endpoint and different credentials, which turns what would be a rewrite into a configuration change and a data copy. Layered on top is global replication, so objects sit near the users requesting them rather than in one region everyone reaches across an ocean. The headline commercial claim is no egress fees, and for a high-bandwidth application, a media-heavy site, or anything serving large files repeatedly, that is where the money is. It is worth being precise about who benefits. If your bandwidth bill is small, this saves you very little and you are switching vendors for a rounding error. Run the actual numbers on your transfer volume before treating it as a decision.
FoundationDB underneath, and the limits of calling it a database
Tigris is built on FoundationDB, a serious foundation for distributed consistency, and there is a data layer alongside the object storage. Be honest with yourself about which product you are buying. The mature, differentiated part is globally replicated S3-compatible storage; the database layer is not where this competes with Postgres, and choosing it for relational application data would be strange when Neon and Supabase exist. Single-region workloads also get much less from it, because global replication is the differentiator and you would be paying for a feature you never use. The vendor risk is the usual one for a smaller proprietary player holding your assets: keep the S3 compatibility genuine in your code, avoid depending on anything vendor-specific, and the exit stays as easy as the entrance was.
Frequently asked questions
Is Tigris S3-compatible?
Yes, and that is the main reason it is worth evaluating. Existing S3 SDK code, upload pipelines, and tooling generally work against a different endpoint and credentials. Keep your code free of vendor-specific extensions and the migration stays reversible, which is the right posture with any smaller proprietary vendor holding your assets.
Does Tigris charge egress fees?
No egress charges are the headline of the product, and that is the whole commercial argument for switching. Whether it matters depends entirely on your transfer volume. For media-heavy applications serving large files repeatedly it can be substantial; for a site with modest bandwidth it is a rounding error and not worth changing vendors over.
Is Tigris a database or object storage?
Object storage first, with a data layer alongside it, built on FoundationDB. The globally replicated S3-compatible storage is the differentiated part. For relational application data, use Postgres, and Neon or Supabase are the sensible picks in this directory. Bringing Tigris in as your primary application database would be using it against its strengths.
Links
Similar tools you should also consider
If Tigris is your pick, the next conversation is short
The 30-min call is where your database choice becomes a real architecture, a migration plan if you are switching, and a price range you can take to your stakeholders. Describe your stack, your scale, your data shape. I tell you whether Tigris is genuinely your fit.