Take the 30% from Glue 6.0, wait on Iceberg v3
September 1, 2026 · 6 min read ·
TL;DR
Glue 6.0 drops the DPU-hour rate from $0.44 to $0.308, but only for jobs moved onto the 6.0 runtime — a real Spark 3.5-to-4.1 upgrade with a payback you can compute. The same release adds Iceberg v3 (deletion vectors, row lineage, variant type), but Athena, Trino, and Snowflake can't read v3 yet, and the v2-to-v3 flip can't be undone. Runtime version and table format version are separate dials: take the price cut now, keep format-version at 2.
AWS doesn't cut list prices on mature services very often. So when Glue 6.0 shipped on August 21 with "30% lower pricing than previous AWS Glue versions," that's worth stopping on. The standard Glue rate has been $0.44 per DPU-hour for years. Glue 6.0 drops it to $0.308. Per-second billing and the one-minute minimum are unchanged. It applies to the ETL jobs and crawlers that make up almost everyone's Glue bill.
Thirty percent off something you were already paying for, with no architecture change, is close to unheard of. But the discount isn't an account-wide toggle. It's attached to the runtime version. A job running on Glue 5.1 keeps paying $0.44. The same job moved to 6.0 pays $0.308. The savings are real, but you have to go get them.
What "move to 6.0" actually involves
AWS's framing is "no API changes are required." That's true, and it's not the whole picture. You select the version with the --glue-version parameter, the job definitions don't change, the APIs don't change. At that layer it's a one-line change.
Underneath, 6.0 is a much newer runtime. Spark goes from 3.5 to 4.1. Python from 3.11 to 3.13. Scala from 2.12 to 2.13. The one that catches people is that Spark 4 turns on ANSI SQL mode by default. That changes how some expressions behave — a division by zero that used to return null now raises, numeric overflow errors instead of wrapping, some casts fail instead of silently producing garbage. For most jobs this surfaces nothing. For a job that was quietly leaning on the old behavior, it's a wrong result or a failed run, and you want to find that in a test run rather than in production.
There's an upgrade agent that analyzes jobs and suggests changes. For a handful of jobs, moving to 6.0 is an afternoon. For an estate of hundreds, it's a small project — but a project with a return you can actually compute. Pull the DPU-hours per job from the last few months, multiply the heavy jobs by the $0.132 per DPU-hour you'd save ($0.44 minus $0.308), and you have the payback. Sequence the migration by that number, not by job count. The ten jobs burning the most DPU-hours are where the money is; the long tail of tiny jobs can wait or ride the auto-upgrade.
The other headline: Iceberg v3
The same release adds support for Apache Iceberg v3, and this is where I'd slow down.
Quick background if you don't live in this. Iceberg is a table format — a layer of metadata over plain Parquet files sitting in S3 that makes a directory of files behave like an actual table. Atomic commits, so a reader never sees a half-written update. Schema changes that don't rewrite the data. Time travel to an earlier snapshot. Without it, a "table" in a data lake is a folder and a prayer.
The format has a spec version, and it's been climbing:
- v1 grouped files into snapshots. You got atomic reads and time travel.
- v2 added row-level deletes without rewriting whole files. Instead of rewriting a 1 GB Parquet file to remove a thousand rows, you write a small "delete file" listing them, and readers subtract at query time. It works, but delete files pile up, and reads slow down until you compact.
- v3 is what Glue 6.0 supports. The parts that matter:
- Deletion vectors replace v2's delete files with a compressed bitmap per data file — one structure, fast to apply. AWS measured reads at least 1.5x faster on an update-heavy table.
- Row lineage gives every row a stable ID and a version number, which is what you need for change-data-capture without bolting on extra tooling.
- Variant type is a column that holds arbitrary JSON without declaring the schema up front, and Glue shreds it into columnar storage so queries stay fast.
- Default column values let you add a column and have old rows pick up the default without a backfill job.
These are good. Deletion vectors alone are a real answer to the merge-on-read tax that anyone running CDC into Iceberg has felt.
Why I'd wait on v3 anyway
A format version is a contract with every single thing that reads the table. And right now, the things that read your tables mostly can't read v3. Athena doesn't support it — Athena still writes v2. Neither does Trino. Neither does Snowflake. If Glue 6.0 writes a v3 table and your analysts point Athena at it, they get an error, not a result.
What makes this more than a wait-a-quarter caution: the upgrade is one-way. Iceberg will let you take a v2 table to v3; it will not let you go back. Setting format-version to 2 on a v3 table is rejected outright. If you flip a production table to v3 and then find a downstream consumer that can't read it, the rollback plan is "rewrite the whole table."
The good news is you don't have to make this decision to get the price cut. The runtime version and the table format version are separate dials. format-version is a per-table property, and it still defaults to 2. Moving a job to Glue 6.0 does not silently start writing v3. I'd go further and set it to 2 explicitly in the table properties rather than trust a default I don't control — but the point stands: the 30% is available today without touching the format.
Two features, one announcement, two decisions
The thing to resist is treating a bundled release as a single yes-or-no. Glue 6.0 put a safe, unconditional price cut and a one-way format migration in the same blog post, and they don't move at the same speed.
Take the 30%. Do the runtime upgrade, sequence it by DPU spend, test for the ANSI-mode surprises, and bank the savings. Pin your tables at format-version=2. Then put a reminder somewhere six months out to check whether Athena, Trino, and whatever else reads your lake have caught up to v3 — and only then, table by table, with the consumers audited, start moving the ones where deletion vectors actually pay for themselves.
Bundled releases invite you to adopt at the speed of the riskiest thing in the bundle. Unbundling them is the whole move. It helps that this one has a number attached to the safe half.
Sources: AWS News Blog — AWS Glue 6.0 now available with 30% lower price and full Apache Iceberg v3 support, AWS — AWS Glue 6.0 delivers 30% price reduction and Iceberg v3 support, AWS Big Data Blog — Introducing AWS Glue 6.0 for Apache Spark, AWS Glue pricing, Google Open Source Blog — What's new in Apache Iceberg v3
The takeaway
Treat a bundled release as separate decisions. Upgrade the Glue runtime to 6.0 and sequence it by DPU spend to collect the 30%. Pin tables at format-version=2 until your read layer supports Iceberg v3, because that upgrade is one-way.