S3-Compatible Object Storage at $15/TB: Read the Egress Math First

A team I advised last year had the headline exactly right and the conclusion exactly wrong. They had read that a rival provider was cheaper per GB, run the storage-line comparison, and concluded the migration was a clear win. The number that actually decided their bill never made the spreadsheet: the egress cost to *leave* their incumbent. Copying 80 TB out cost more than three months of the new service, and the project stalled on that single line. When a storage vendor talks about price, the figure that sets your bill is rarely the one on the pricing page.

That is the lens I bring to Filebase's announcement, covered by StorageNewsletter on June 10, 2026: the company is returning to pure S3-compatible object storage at a flat $15/TB per month with free egress, after years spent building on IPFS and decentralized networks like Sia and Storj. Co-founder Joshua framed the pivot bluntly: storage "shouldn't punish you every time you need to retrieve your own data."

The per-TB rate is the least interesting part, since Cloudflare R2 already sits at the same $0.015/GB. The egress decision is what merits a close look, along with what it does and does not buy you.

I write this from Rabata.io, where we run our own S3-compatible storage, so I have a stake in this market. That is exactly why I am keeping the assessment factual: free egress is a real economic lever for some workloads and an irrelevance for others, and the difference is entirely about how your data moves.

Free Egress Is a Workload Decision Before It Is a Headline

Filebase keeps storage at $15/TB and charges nothing to read data back out. To see why that matters, you have to add the second axis most pricing tables hide. For a workload of 1 TB stored plus 1 TB read out in a month, the research that accompanied this launch puts the totals at roughly $15 for Filebase, about $73 for AWS S3 (storage near $23/TB plus egress at $0.05–$0.09/GB), and close to $100 for Google Cloud Standard once transfer is counted. The storage line is a rounding error next to the transfer line.

But invert the workload and the advantage evaporates. A cold backup archive that you write once and almost never read pays almost no egress anywhere, so free egress saves you nothing; Backblaze B2 at $0.006/GB storage would beat $15/TB outright for that profile. Free egress is decisive for read-heavy patterns: AI training jobs re-reading datasets every epoch, media libraries serving global traffic, SaaS apps streaming user uploads. It is close to noise for write-once-read-rarely archives.

Run that classification before you run the migration. The vendor cannot tell you which row you are in; only your access logs can.

The Numbers Worth Trusting, and the One I'd Hedge

Two structural claims here are grounded and load-bearing. The first is operational reach. Filebase supports individual objects up to 1 TB, against the 5 GB per-object cap on Vultr and Linode. That gap is real if you back up large database dumps or video masters as single files, and it explains why those providers force you into awkward sharding. AWS S3, for contrast, now allows objects up to 50 TB, so Filebase sits in the middle of the pack rather than at the top.

The second claim is the gateway ceiling: standard gateways are rate-limited to roughly 100 requests per second, with dedicated gateways removing the limit. That 100 RPS figure is the one I would put on a sticky note before migrating any high-concurrency pipeline, because it bites quietly. Small-object, metadata-heavy access patterns hit it long before bandwidth becomes the issue.

The claim I distrust is the "up to 18x faster than Cloudflare R2" performance number. It appears only in Filebase's own marketing materials, scoped to "certain workloads," with no published methodology. I do not repeat vendor speed multipliers without a reproducible benchmark, and neither should you. If raw throughput is your gating factor, demand the test harness - instance type, concurrency, object size, network - before you let a multiplier into your decision.

What is verifiable on the integrity side is plainer and more useful: every object is checksummed with SHA-256, so the service can confirm bit-for-bit accuracy on write and detect corruption on read. That is table stakes for a backup target, and it is the kind of claim a vendor should make in place of a speed multiplier.

What "Bare Metal, Operated End-to-End" Buys You - and Costs You

Filebase's other headline is that it now runs on bare metal infrastructure the company operates itself, end-to-end, having shed the decentralized-network abstraction that used to sit underneath. There is a genuine engineering argument here: owning the hardware removes a layer of aggregation, and it lets one team tune the whole path instead of inheriting another network's behavior. For the read-consistency and upload-speed complaints that drove the pivot, that vertical control is the plausible fix.

The counterweight worth stating plainly is concentration. A single operator running a single stack is a single failure domain. AWS S3 spreads objects across availability zones by design; a multi-cloud posture spreads risk across vendors. Filebase's stated 3x redundancy addresses device failure, not provider failure: if the operator has a bad day, your data has a bad day. For primary, can't-lose data, I would still keep an independent copy on a second provider regardless of how clean the bare-metal story sounds. Free egress, conveniently, makes that second-copy hygiene cheaper to maintain, which is the rare case where a marketing feature and good DR practice point the same direction.

A Pre-Migration Checklist That Catches the Expensive Mistakes

Because S3 compatibility means your existing tools (AWS SDKs, rclone, restic, Terraform) keep working by changing an endpoint, the migration looks deceptively trivial. The expensive failures are never about the SDK. They are about the things below. Work through them in order:

1. Pull your egress numbers first. Three months of transfer-out volume tells you whether free egress is your lever or a distraction. Decide which row of the table above you are in before anything else.
2. Inventory object sizes. If anything exceeds 5 GB, confirm your client uses multipart upload; if anything approaches the 1 TB ceiling, plan for resumable transfers, because a dropped connection on a single huge object is an expensive restart.
3. Load-test against 100 RPS. Replay a realistic request mix at the standard gateway limit. If your access pattern is metadata-heavy, budget for a dedicated gateway up front instead of discovering throttling in production.
4. Verify checksums on cutover. Compare SHA-256 hashes source-to-destination on a sample before you trust the copy, and never delete the origin until that comparison passes.
5. Keep a second copy of primary data. A bare-metal single operator is one failure domain; treat it accordingly for anything irreplaceable.
6. Compute the egress cost of leaving in advance. Whatever you migrate onto, you will someday migrate off. Know that exit cost now.