Where we are in the stack
b1 gave you eight layers and the chokepoint frame: in every layer there is a narrow waist where truth is decided and where lock-in actually lives. Tonight covers layers one and two. Layer one is storage, and its chokepoint is egress economics plus retention terms - what it costs to read your own data, and whether you can leave. Layer two is the table format, the transactional metadata that makes object storage behave like a database. Both layers unblock nobody on their own, which is precisely why they get underfunded and why everything above them fails when they are skipped.
Storage is cheap, reading it is not 8 min live
Every price below was fetched on 6-7 August 2026, from the vendors' own machine-readable billing feeds where one exists (AWS Price List API, Azure Retail Prices API) and from the published rate card otherwise. Read the two columns separately. The storage column is a normal competitive market with roughly a 3x spread. The egress column is not a market at all - it is a strategic weapon, and the gap between $0 and $0.09 per GB is what actually shapes where your compute has to live.
| Provider (first tier, fetched 2026-08-06/07) | $/TB-month | Egress to internet |
|---|---|---|
| Wasabi Pay-Go | $7.99 | $0, but capped 1:1 against stored volume |
| Cloudflare R2 Standard | $15.36 ($0.015/GB) | $0, no ratio clause |
| Cloudflare R2 Infrequent Access | $10.24 ($0.01/GB) | $0 plus $0.01/GB retrieval, 30-day minimum |
| Azure Blob Hot LRS (East US) | ~$21.30 ($0.0208/GB) | 100 GB free, then $0.08/GB |
| AWS S3 Standard (us-east-1) | ~$23.55 ($0.023/GB) | 100 GB free, then $0.09/GB |
LiveThe ratio: 3.9x, and why it moves your compute4 min▶
Here is the single number to carry out of this session. On AWS S3, storage is $0.023 per GB-month and egress to the internet is $0.09 per GB after the free allowance. Downloading a byte once costs about 3.9x storing it for a whole month. Not 4% more. Nearly four times.
The published S3 egress tiers, from the Price List API with publicationDate 2026-08-06: the first 100 GB per month is free (account-wide, across all regions), then $0.090/GB up to 10 TB, $0.085/GB for the next 40 TB, $0.070/GB for the next 100 TB, and $0.050/GB above 150 TB. Storage tiers down too, but far more gently: $0.023, then $0.022 above 50 TB, then $0.021 above 500 TB.
The headline arithmetic: egressing 100 TB in one month costs $0 on Cloudflare R2, $0 on Wasabi only if you also store at least 100 TB, and about $8,563 on AWS. Storage prices differ roughly 3x across vendors. The egress gap is effectively infinite.
This ratio is why "just point the BI tool at the data lake" is an architecture decision and not a convenience. Every design pattern you have been told is best practice - keep compute in the same region as storage, cache aggressively, push filters down into the scan, prune columns and partitions - is at least partly a reaction to a single line on a rate card. The b1 trap lever costs $1,784 a month for exactly the same work, and the work did not change. Only the path the bytes took did.
LiveThe fine print that turns a cheap price into a commitment5 min▶
Wasabi is the cheapest storage line on the table by a wide margin, and there are three published conditions attached. All three are on Wasabi's own pages. Read them in order.
1 · The 1:1 free-egress policy, verbatim. Wasabi states: "If your monthly egress data transfer is less than or equal to your active storage volume, then your storage use case is a good fit for Wasabi's free egress policy." And, for the other side of that line: "If your monthly egress data transfer is greater than your active storage volume, then your storage use case is not a good fit", with the consequence stated as "we reserve the right to limit or suspend your service."
Read that consequence carefully, because it is the whole point. This is a terms-of-service risk, not a metered overage. There is no published penalty rate. If you exceed the ratio on S3 you get a larger invoice, which is unpleasant but predictable and can be modelled. If you exceed it here, the published remedy is limitation or suspension of service. Those are materially different risk profiles, and a finance-led vendor comparison that only compares dollar figures will not surface the difference at all.
2 · Minimum storage duration, verbatim: "if stored objects are deleted before they have been stored with Wasabi for a certain number of days, a Timed Deleted Storage charge equal to the storage charge for the remaining days will be applied." That period is 90 days on Pay-Go and 30 days on Reserved Capacity.
3 · A 1 TB minimum billing on Pay-Go (10 TB for Cloud NAS).
Put the three together and the conclusion is specific rather than negative: Wasabi is actively bad for short-lived, high-churn data. Staging areas, scratch space, CI artifacts, anything with a 7-day lifecycle rule - you pay 90 days for 7 days of use. For large, cold, rarely-rewritten archives read at a modest ratio, the same rate card is excellent. The vendor is not the answer; the workload shape is.
Self-studyR2's stronger claim, and the 10% operations undercut3 min read▶
Cloudflare R2 is more expensive per TB than Wasabi and cheaper than S3, and it makes the stronger of the two zero-egress claims: there is no ratio clause at all. When you compare "free egress" offers, that clause is the entire comparison. One is free egress; the other is free egress within a bound, enforced by a right to suspend.
R2 also prices operations exactly 10% under AWS, which is too precise to be a coincidence and reads as deliberate positioning:
- Class A (writes and lists) $4.50/million vs S3 PUT/COPY/POST/LIST $5.00/million.
- Class B (reads) $0.36/million vs S3 GET $0.40/million.
The strategic reading: zero egress is the headline, and the 10% undercut removes the obvious counter-argument that operations charges quietly claw the savings back. Note that operations matter enormously for small-file workloads - a table with millions of tiny Parquet files pays in request count, not in bytes, which is one of several reasons compaction exists.
Self-study"But AWS made egress free" - what that announcement actually says2 min read▶
You will hear this in vendor conversations, so know the shape of it. AWS announced free transfer-out for customers migrating off AWS on 2024-03-05, and it is still live. Four qualifiers, all from AWS's own terms:
- Request-based - you apply, it is not automatic.
- Approval-gated - AWS decides.
- Credited after the fact - you pay the egress, then receive a credit.
- Time-boxed to 90 days.
And the motivation is regulatory: the EU Data Act, not competitive repricing. This is an exit path, not a rate-card change. It does nothing for the ordinary case that dominates your bill, which is reading your own data every day while staying exactly where you are. Treat it as evidence that egress pricing is now a policy question in Europe, and price your architecture on the standing rate card.
Price the same 50 TB three ways ★ 12 min · everyone runs it
The simulator below is in egress mode. It holds your stored volume and your monthly egress volume and recomputes each vendor's bill live from the published tiers fetched on 6-7 August 2026 - including the S3 egress bands, so the marginal rate falls correctly as volume rises. Start with the defaults, then push the egress slider past your stored volume and watch what happens to the Wasabi row.
Defaults are 50 TB stored, 20 TB egressed per month. Read the three bills: Wasabi $400, Cloudflare R2 $768, AWS S3 $2,961. Annualized that is $4,794, $9,216 and $35,533.
Now decompose the S3 number. Of that $2,961, $1,784 is egress and only $1,177 is storage. Egress is 60% of the S3 bill at a ratio most teams would call modest. Nobody budgets for the 60%; everybody budgets for the 40%.
S3 costs $2,193 a month more than R2 - $26,317 a year, and almost all of the difference is one line item. That is the salary line of a junior engineer, spent on the privilege of reading data you already own.
Drop egress to near zero and watch the three bills converge toward the storage-only spread. This is the honest version of the vendor comparison: at low read ratios the vendors look similar; at high read ratios they are not in the same business.
Now push egress above stored volume - try 50 TB stored and 60 TB egressed. The Wasabi row flips to a warning, because you have left the 1:1 free-egress policy. Note what the warning does not say: it does not quote a penalty rate, because there is not one. It is a suspension risk.
Finally, set the inputs to your own organization's real numbers if you know them. If you do not know your egress volume, that is itself the finding, and it is the first homework item.
What a table format actually adds 10 min live
Start from the deficit, not the feature list. Object stores give you cheap, durable, effectively unlimited scale with no transactions, no schema enforcement, and no atomic multi-file operations. A "table" on object storage is a directory of Parquet files. If a writer crashes halfway through replacing forty of them, readers see forty files from two different states and nothing tells them so. Open table formats exist to close exactly that gap: they add a transactional metadata layer over immutable data files. The data files were never the problem.
LiveIceberg v3: deletion vectors, row lineage, VARIANT, geospatial4 min▶
The v3 spec landed in 2025 and four additions matter for platform work:
- Deletion vectors - row-level deletes without paying the merge-on-read cost on every query.
- Row lineage - a row ID plus a last-modified sequence number. This is the one to underline: it makes incremental processing and CDC a query rather than a diff job. Instead of comparing two snapshots yourself and reasoning about what changed, you ask the table which rows moved since a sequence number. A large category of bespoke pipeline code stops needing to exist.
- VARIANT type - semi-structured data as a first-class column rather than a string you re-parse on every read.
- Geospatial types.
Delta Lake and Apache Hudi solve the same core deficit with different mechanics and different histories - Hudi in particular came out of upsert-heavy ingestion at Uber and shows it in the design. All three are real, production-grade, and running enormous workloads today. The question worth your time is not which is technically superior. It is which one your engines, your catalog and your vendors will all still speak to in five years.
LiveThe format war is settled directionally - here is the evidence5 min▶
Be careful about how strong a claim you make here, because there is no trustworthy public market-share measurement for Iceberg versus Delta and any number you are shown is a vendor artifact. What is observable is the direction of the engineering, and it points one way.
The two structural tells:
- Both competitors build translation layers pointing AT Iceberg. Delta ships UniForm, which generates Iceberg metadata alongside Delta metadata. Hudi is paired with Apache XTable, which translates between formats. Nobody builds a bridge toward a destination they expect to be abandoned.
- Both Databricks and Snowflake ship managed Iceberg. The company that owns Delta and the company that seeded Polaris both sell you Iceberg as a managed product. Watch what vendors build, not what they say in a keynote.
The dated record, in order:
| Date | Event | How to label it |
|---|---|---|
| 2024-06-03 | Snowflake announces Polaris | vendor announcement |
| 2024-06-04 | Databricks agrees to acquire Tabular, the company founded by Iceberg's creators, reported north of $1B | REPORTED - press-reported, never disclosed by either party. Cite the acquisition as fact, the price as reporting. |
| 2024-12-03 | AWS ships S3 Tables | vendor release |
| 2026-02-19 | Apache Polaris graduates to Top-Level Project | ASF governance fact |
| 2026-05-28 | Databricks ships Iceberg v3 GA plus managed Iceberg in Unity Catalog | vendor release, Databricks' own blog |
Two of those dates are one day apart. Snowflake announced Polaris on 3 June 2024 and Databricks agreed to acquire Tabular on 4 June 2024. That is not a coincidence of the calendar, it is two companies deciding in the same week that the interoperability layer was the thing worth owning. b3 picks up exactly where this leaves off, because the fight then moved one layer up, to the catalog.
LiveXTable translates metadata, not data4 min▶
Say this one out loud in class, because almost everyone assumes the opposite. Apache XTable translates METADATA, not data. Students hear "converts between Iceberg, Delta and Hudi" and picture a job that rewrites terabytes of files. It does not. There is nothing to rewrite.
The Parquet was always compatible. All three formats store the same columnar data files. Only the metadata dialects differed - how a snapshot is described, how manifests are laid out, how a commit is sequenced. XTable reads one dialect and writes another over the same untouched data files. The same is true of Delta UniForm, which generates Iceberg metadata over Delta data files, and of OneLake metadata virtualization.
Two consequences fall straight out of that, and they are why this matters beyond trivia:
- Translation is cheap and fast, because it is metadata-sized rather than data-sized. That is why interop arrived so quickly once vendors decided to build it.
- Translation is a second source of truth. Which brings us to the trade-off nobody markets.
LiveWhat is a proposal and must not be taught as fact2 min▶
Databricks has proposed that Delta 5.0 adopt Iceberg v4's adaptive metadata tree, which would eliminate translation layers by making the two formats converge on one metadata structure. It is a coherent proposal and it would be genuinely good news if it ships.
Iceberg v4 and Delta 5.0 are proposals. Neither has shipped. Do not teach convergence as an accomplished fact, and be alert when a vendor deck presents it as one - the roadmap slide and the release-notes slide are different documents with very different obligations behind them. Design your architecture against what is GA today, and treat convergence as an upside case that reduces the cost of a decision you already have to make.
One related discipline for the same reason: medallion (bronze/silver/gold) is a naming convention, not a technology. Nothing in Delta, Iceberg or Hudi enforces it. Its value is a shared vocabulary for "how cleaned is this table," and its common failure is silver being bronze with renamed columns while gold is forty unmaintained project tables. b5 covers that honestly.
Try it yourself - this week ◐ 30 min total
- Find your actual monthly egress volume and your actual stored volume, and compute the ratio. Most teams cannot answer this from memory, and a surprising number cannot answer it from their billing console without help. The ratio, not the absolute number, is what decides whether a zero-egress vendor is interesting to you.
- Take the two lowest-priced storage options you would realistically consider and write down, for each, the retention minimum, the billing minimum, and the exact remedy for exceeding any usage policy. Then mark which remedies are billed and which are contractual. That second column rarely appears in an internal comparison deck.
- Pick one table in your platform and answer: which format is it in, who wrote that metadata, and is any of it derived by a translation layer rather than written authoritatively? If the answer involves UniForm or XTable, note what would happen if the derived side drifted.
- Audit one vendor deck you have been given in the last year for the convergence claim. Is Iceberg v4 or Delta 5.0 presented as shipped? Roadmap presented as fact is the single most common failure mode in this category, and spotting it is a transferable skill.
Official sources covered
Prices came from machine-readable billing feeds wherever one exists, never from marketing pages, and every figure carries the date it was fetched. Vendor claims are labelled as claims. This page covers:
Three questions before you go 🎯 ◐ 90 seconds
1 · On AWS S3 at list price, how does the cost of reading a byte out compare with the cost of storing it?
That ratio is the reason your compute has to sit next to your storage, and the reason pushdown, pruning and caching are architecture rather than tuning. Egressing 100 TB in a month is $0 on R2 and about $8,563 on AWS. Prices fetched 2026-08-06/07.
2 · You exceed Wasabi's 1:1 free-egress ratio for three months running. What actually happens?
There is no penalty rate, because it is not a metered overage. That is a materially different risk profile from a larger invoice: one is predictable and can be modelled, the other is a service-continuity question. A comparison that only lines up dollar figures will never surface it.
3 · A colleague says XTable will let you "convert 400 TB from Hudi to Iceberg." What is the correction?
Same for Delta UniForm and OneLake metadata virtualization. Because translation is metadata-sized it is cheap and fast - and because it produces a derived rather than authoritative metadata copy, it is also a second source of truth that can drift.