AWS Redshift RG: Graviton Climbs Into the Analytics Stack

The platform decision that lands on a CTO's desk this quarter is no longer "warehouse vs. lakehouse." It's whether the next three-year analytics commitment gets written on x86 Snowflake credits, Databricks DBUs, or Arm-flavored Redshift. AWS just made the third option meaningfully harder to ignore, and the unit economics are the reason.

What Happened

This week AWS launched Graviton-powered RG instances for Amazon Redshift, as Data Center Knowledge reported on May 15. The headline numbers from AWS: up to 2.2x faster data warehouse performance versus the previous RA3 generation, at 30% lower cost per vCPU. Apache Iceberg workloads run up to 2.4x faster, Apache Parquet up to 1.5x faster, both measured against RA3.

The structural change matters more than the benchmark slide. RG instances collapse warehouse and data lake querying into a single engine. AWS says queries against warehouse-resident data and against open table formats on S3 now run from the same compute layer, without the separate Redshift Spectrum infrastructure that historically charged per terabyte scanned. Those scan fees are gone for this path.

AWS positioned the instances explicitly for "analytics and agentic AI workloads" that need lower-latency access to large datasets. The internals: a built-in vectorized query engine processes Iceberg and Parquet data directly on cluster nodes, and local NVMe caching keeps hot datasets close to compute.

Matt Kimball, vice president and principal analyst for datacenter technologies at Moor Insights & Strategy, told Data Center Knowledge that "AWS is addressing significant challenges that are of concern to every enterprise, performance, TCO, and complexity." On the price/performance delta, he was blunt: "When looking at numbers like 2.2x faster for data warehouse workloads and 2.4x for Apache Iceberg alongside a 30% lower price per vCPU, it's hard to see this as incremental in that cost/performance metric." Kimball also flagged the strategic read: "AWS does seem to be pulling its silicon up the stack. Not just into infra like EC2, but into the data and analytics layer itself."

Technical Anatomy

Three pieces of plumbing are doing the work here, and platform leads should understand each independently because they have different lifespans on a roadmap.

First, the silicon. Graviton is AWS's custom Arm processor family. Pushing it under Redshift means AWS owns the margin stack from the wafer up to the SQL parser. That's how a 30% per-vCPU price cut coexists with a performance bump: AWS isn't reselling Intel or AMD silicon at this layer, so it can price against its own cost curve rather than a vendor's. Snowflake and Databricks, both of which run on someone else's compute, cannot match that math without renegotiating the substrate they sit on. Snowflake customers reading the credit model should think about who absorbs Arm's cost advantage over the next renewal cycle.

Second, the engine. Historically Redshift queried external S3 data via Redshift Spectrum, a separate service with its own infrastructure and per-terabyte scan billing. The RG architecture eliminates that hop. A vectorized engine on the cluster reads Iceberg and Parquet directly, with local NVMe caching for the working set. This is the same architectural direction ClickHouse took years ago: vectorized execution close to storage, with aggressive caching. AWS arriving at this design tells you where mainstream cloud analytics is settling.

Third, the table format. Iceberg is now a first-class citizen in Redshift's compute path, not a federated guest. That's a quiet but significant bet: AWS is signaling that customer data will live in open formats on object storage, and the warehouse becomes a query engine you rent on top of it. The lock-in shifts from data gravity to engine ergonomics, which is a very different negotiation when contract renewal comes around.

The "agentic AI" framing is marketing, but the substrate is real. Agent workloads generate bursty, unpredictable read patterns against wide datasets. Per-TB scan fees made that financially hostile. Removing them changes which workloads are economically viable to run interactively.

Who Gets Burned

Start with the obvious target: Snowflake's mid-market account base. Teams running steady-state warehouse workloads on Snowflake with growing Iceberg ambitions are exactly the segment AWS just priced against. The 30% per-vCPU delta won't translate one-for-one into a 30% bill reduction (workloads aren't apples-to-apples), but it gives a CFO enough ammunition to demand a renewal discount or open a parallel POC. Snowflake's recent Iceberg push was meant to defend this flank. It now has to defend it on price too.

Databricks is less directly exposed because its center of gravity is ML and Spark workloads on Delta Lake, but the Iceberg performance numbers compress the analytics-only use case where Databricks SQL competes with Redshift. Expect sharper Photon pricing conversations.

Inside enterprise IT, the burn is more interesting. Data platform teams that built elaborate Spectrum-to-Redshift cost-management tooling, query routers, scan budget alerts, materialized view strategies designed to avoid per-TB fees, just watched a chunk of that work become legacy. Kimball's own framing applies: "As an enterprise IT leader, I want to reduce how much I have to duplicate and move data." The teams that built their careers on managing the duplication and movement now have a smaller surface to defend.

The CFO at any series-B fintech or iGaming operator running Redshift should be asking the VP Engineering this week: what does our annualized Redshift bill look like on RG instances at current workload, and what's the migration cost to find out? That's a two-week spike, not a quarter-long initiative, and the answer reframes the FY27 data platform budget. If the VP Eng can't produce a number within ten business days, the data org has a planning problem independent of AWS.

Regulated verticals get a secondary benefit. Collapsing Spectrum into the core engine reduces the number of service boundaries auditors have to reason about. Fewer per-service logs, fewer IAM surfaces, fewer billing line items to reconcile against data residency claims. GCs at licensed operators should welcome that, quietly.

Playbook for Data Teams

Concrete moves for the next 30 to 90 days, ordered by use.

Run the RG benchmark on your actual workload, not AWS's. The 2.2x and 2.4x figures are vendor-published. Pick your three most expensive recurring queries (the ones product managers complain about) and your two highest-scan-cost Spectrum jobs, replay them on an RG cluster, capture both wall-clock time and projected monthly spend. That data is the use at the next Snowflake or Databricks renewal even if you never migrate.

Audit your Iceberg readiness. If your lake is still Parquet-on-S3 with Glue catalog and no table format, you're leaving the larger half of the performance gain on the table. Iceberg adoption is now a procurement decision, not just an engineering preference. Document the migration path and cost.

Re-examine your semantic layer. If transformations live in dbt against Redshift, the migration story is straightforward, models are warehouse-portable. If they live in Snowflake-specific or Databricks-specific constructs, the lock-in cost just became a line item worth quantifying.

Talk to your AWS account team about committed-use discounts on RG before the standard list price becomes the negotiating floor. New-instance launches are the window where AWS reps have the most flexibility. That window is open now and closes once the SKU is mainstream.

Finally, on hiring: Arm-native performance tuning is a niche skill that's about to matter more. The pool of engineers who can profile a vectorized query engine on Graviton and reason about NVMe cache locality is smaller than the pool that can tune a Snowflake warehouse. Adjust JD language and comp bands accordingly before the market does.

Key Takeaways

• AWS Redshift RG instances claim up to 2.2x faster warehouse performance and 30% lower cost per vCPU than RA3, with Iceberg workloads up to 2.4x faster.
• The integrated engine eliminates separate Redshift Spectrum infrastructure and its per-terabyte scan charges, changing the unit economics of lake querying.
• AWS owning the silicon-to-SQL stack via Graviton is a structural pricing advantage Snowflake and Databricks cannot easily match at the substrate level.
• The competitive pressure lands hardest on mid-market Snowflake accounts with Iceberg ambitions, and on internal cost-management tooling built around Spectrum's billing model.
• Teams evaluating their FY27 analytics platform commit should now be asking what their actual workload costs on RG, before the next renewal conversation with any incumbent vendor.