AWS Glue 6.0: 30% Cheaper, Iceberg v3, Spark 4.1

AWS Glue 6.0 cuts pricing by 30%, adds full Apache Iceberg v3, and moves to Apache Spark 4.1, so migrating your ETL jobs is both a cost win and a toolchain upgrade, if you plan for the runtime jump. On August 21, 2026, AWS made Glue 6.0 generally available. The catch: Spark 4.1 can break jobs built for older runtimes, so the savings come with a short migration. At Van Data Team, we help teams capture the win without the outage.

Key Takeaways

• On August 21, 2026, AWS made Glue 6.0 generally available with 30% lower pricing than previous versions.
• Glue 6.0 adds full Apache Iceberg v3 support, built on Iceberg 1.11.0, and upgrades the runtime to Apache Spark 4.1, Python 3.12, and Scala 2.13.
• Iceberg v3 brings the VARIANT type, deletion vectors, geometry and geography types, and flexible schema evolution, all real capabilities, not cosmetic ones.
• New productivity features include Spark Declarative Pipelines, Arrow-native Python UDFs, and a real-time streaming mode with single-digit millisecond latency.
• Van Data Team's recommendation: the 30% cut makes migrating worth it for active jobs, but test on Spark 4.1 first and move in batches, not all at once.

What Did AWS Actually Ship?

AWS shipped a cheaper, more capable Glue that also moves you onto a newer, and slightly riskier, runtime.

Reported fact: On August 21, 2026, AWS announced the general availability of AWS Glue 6.0. The headline is 30% lower pricing than previous AWS Glue versions, on the same serverless ETL service. Underneath, the runtime moves to Apache Spark 4.1, Python 3.12, and Scala 2.13.

The table-format story is the other headline. Glue 6.0 adds full support for Apache Iceberg v3, built on Iceberg 1.11.0, plus newer versions of Apache Hudi and Delta Lake. So this is both a price cut and a lakehouse upgrade in one release.

It also adds developer and performance features, which the next sections cover in detail. To adopt any of this, you select Glue 6.0 in the console or SageMaker Unified Studio, or migrate existing jobs with the Spark Upgrade Agent.

What Are the New Speed Features in AWS Glue 6.0?

Beyond price and Iceberg, AWS Glue 6.0 ships features that change how fast you build and run jobs.

• Spark Declarative Pipelines. You describe what the pipeline should produce, and Glue handles the orchestration, cutting the repetitive boilerplate that clutters most ETL code.
• Arrow-native Python UDFs. PySpark UDFs used to pay a serialization tax moving data between the JVM and Python. Arrow-native UDFs remove much of that overhead, so Python transforms run closer to native speed.
• Real-time streaming mode. For jobs that need it, Glue 6.0 targets single-digit millisecond latency, pushing Glue further into territory that used to require a separate streaming stack.

Van Data Team analysis: These aren't headline features, but they're the kind that quietly save engineering time. Declarative pipelines mean less orchestration code to maintain. Arrow UDFs mean your existing Python transforms get faster once you're on 6.0. And the real-time mode matters if you've been stuck on batch because streaming felt like too much machinery.

None of them force a change; they reward teams that adopt 6.0 anyway for the price cut. So the 30% saving isn't the only reason to move. You also land on a runtime that's meaningfully more productive, which makes the migration easier to justify to the people who own the pipelines.

What Does the AWS Glue 6.0 Price Cut Mean?

The 30% cut is a direct reduction on the compute you already pay for, which makes it one of the rare upgrades that pays for its own migration.

Van Data Team analysis: ETL cost is mostly compute, and Glue bills for the compute your jobs consume. A 30% lower rate on the same jobs is a real line-item reduction, not a rebate you have to chase. For a team spending heavily on analytical processing, that compounds fast across a fleet of daily jobs.

The honest caveat is that headline percentages hide job-level detail. Your actual savings depend on your job mix, runtimes, and how efficiently your jobs are written. A wasteful job is still wasteful at a lower rate. So model the savings on your real spend, and pair the migration with basic efficiency hygiene, the same cost discipline we cover in reducing AWS costs through data engineering.

The strategic point is simple. When the platform gets 30% cheaper for the same work, doing the migration is usually cheaper than not doing it. The question isn't whether to move; it's how to move without breaking anything.

What Does the 30% Cut Look Like in Dollars?

A quick illustration makes the saving concrete. Suppose a team spends $10,000 a month on Glue compute across its ETL fleet. A 30% cut on the same jobs is $3,000 a month, or $36,000 a year, for a migration that takes days, not months.

Now scale it up. A larger platform spending $50,000 a month saves $15,000 a month, which is $180,000 a year. At that size, the migration effort is a rounding error against the annual saving, and every month you delay is money left on the table.

The numbers are illustrative, and your real figure depends on your job mix. But the shape holds. The saving is proportional to your current spend, it recurs every month, and it applies to work you're already doing. That's why this migration usually pays for itself in the first billing cycle after you cut over.

What's New in Apache Iceberg v3?

Apache Iceberg v3 is where Glue 6.0 earns its keep beyond price, because these are features teams have actually been waiting for.

Van Data Team analysis: Iceberg v3 isn't a version bump for its own sake. The table below names the features that matter for real data platforms.

Deletion vectors alone are a big deal. Row-level updates on large tables used to mean expensive rewrites, and this makes them far cheaper. VARIANT matters if you ingest messy, semi-structured data and were tired of flattening it up front. And the spatial types open the lakehouse to a whole class of geo workloads it handled awkwardly before.

Should You Migrate to AWS Glue 6.0?

For most active ETL workloads, yes, because the price cut applies to work you're already doing and the Iceberg v3 features are real. The one thing to respect is the Spark 4.1 jump.

Van Data Team analysis: A major Spark version is not a free swap. Spark 4.1 can change SQL behavior, remove deprecated APIs, and shift defaults. Jobs that rely on a Spark 3.x quirk, a removed function, or a specific Python or Scala version are the ones that pass today and fail on the new runtime.

So sort your jobs by risk before you move any of them:

• Active, high-spend jobs: migrate first, because that's where the 30% saving lands hardest.
• Fragile, rarely-touched jobs: run a careful test pass before they move, since they're most likely to assume the old runtime.
• Hard old-runtime dependencies: these need a plan, not a flip, and sometimes a code change.

This is the same workload-fit thinking we bring to modern data pipeline design: match the move to the job, don't treat the fleet as one thing.

The goal is to capture the saving without trading it back in an incident. A migration you tested is a cost win. A migration you rushed is a broken pipeline at 2 a.m.

How Do You Migrate to AWS Glue 6.0 Safely?

Migrate safely by testing your real jobs on Glue 6.0 first, using the Spark Upgrade Agent, and moving in batches rather than all at once.

The work is bounded, and the payoff is a permanent 30% lower bill on migrated jobs. Here's the sequence:

• Inventory your jobs: list every Glue job, its runtime, and its monthly cost, so you migrate the expensive ones first.
• Test on 6.0: run your real jobs on Glue 6.0 in a non-production setup, and validate both the output and the cost.
• Use the Spark Upgrade Agent: let it flag and help fix Spark 4.1 incompatibilities instead of hunting them by hand.
• Watch for behavior changes: check SQL results, null handling, and timestamps, where Spark upgrades often shift.
• Migrate in batches: move a group of jobs, confirm they're stable and cheaper, then move the next group.
• Track the savings: compare before-and-after cost per job, so the 30% shows up in your bill, not just the release notes.

Speed and cost discipline reinforce each other here, and it's the same guardrail mindset we describe in our guide to cloud cost optimization for data platforms: capture the saving, but keep the controls that stop a rushed change from becoming an outage.

Do You Need to Rewrite Your Iceberg Tables?

A fair question before migrating: does moving to Iceberg v3 force a painful table rewrite? For most teams, the answer is reassuring.

Existing Iceberg tables keep working. Iceberg's format versions are built for compatibility, so your current tables read and write on Glue 6.0 without a forced migration. You opt into v3 features table by table, when you want them, not all at once.

That matters for planning. It means the runtime migration and the table-format upgrade are two separate decisions. You can move your jobs to Glue 6.0 to capture the 30% saving now, and adopt v3 features like deletion vectors or VARIANT later, on the tables where they actually help.

So don't let "we'd have to rewrite everything" stall the migration. The price cut is available the moment your jobs run on 6.0. The Iceberg v3 features are a menu you work through afterward, on your own schedule, table by table.

Still, validate the read path during your test pass. Read your existing tables on Glue 6.0 and confirm the outputs match what your current runtime produces, before you route production traffic. Compatibility is designed in, but a test that proves it on your real tables is worth more than an assurance in the release notes. It's a small check that turns "should work" into "does work" for your specific data.

How Van Data Team Helps

Van Data Team treats a Glue upgrade as a costed, testable migration with a clear payoff, not a risky big-bang. We start by inventorying your jobs and ranking them by spend and risk.

Then we test the high-value jobs on Glue 6.0, use the Spark Upgrade Agent to clear Spark 4.1 incompatibilities, validate outputs and cost, and migrate in batches with a rollback path. If you want help, our data pipeline engineering services can run the whole migration, capture the 30% saving, and adopt the Iceberg v3 features that fit your platform. The goal is a lower bill and a modern lakehouse, without a broken pipeline in between.

Take the 30% Cut, but Test First

AWS Glue 6.0 is one of those rare releases that gets cheaper and more capable at the same time, and the smart move is to migrate deliberately rather than skip the saving or rush the jump.

The upside is real: 30% lower pricing, full Apache Iceberg v3 with features teams actually wanted, and a modern Spark 4.1 runtime. The only cost is a short migration to make sure Spark 4.1 doesn't break your jobs. That's a trade almost every team should take.

The next step is small, and you can start it this week:

• Inventory your Glue jobs and rank them by monthly spend.
• Test your single most expensive job on Glue 6.0 in a non-production setup.
• Confirm it's both correct, same outputs, and cheaper, then plan the rest by batch.

Do that, and the migration pays for itself in the first billing cycle, with the Iceberg v3 upside still ahead of you. Explore more data engineering and cloud-cost guidance from Van Data Team, or use the checklist above to plan your move to AWS Glue 6.0.