RDS PostgreSQL on Graviton: Benchmarks, Cost Savings, and the RI Strategy That Stacks Both

Also read: RDS Reserved Instances: complete guide — includes PostgreSQL RI size flexibility rules 

The Benchmark Numbers Behind Each Generation’s Claims

Graviton2 vs x86: Up to 20% Better Price-Performance

The 20% price-performance improvement of Graviton2 over x86 Intel reflects the combination of a lower hourly rate (approximately 10% cheaper than equivalent Intel instances) and comparable or better raw throughput. For PostgreSQL specifically, Graviton2 showed consistent improvements in queries per second for read-heavy OLTP workloads in AWS’s internal benchmarks.

The improvement was not uniform across all workloads — write-heavy workloads with high fsync rates showed smaller gains, while read-heavy workloads and CPU-intensive query processing showed larger gains. Source: AWS official Graviton2 RDS launch documentation (2021), cloudburn.io citing AWS benchmarks.

Graviton3 vs Graviton2: Up to 30% Performance, 27% Better Price-Performance

The Graviton3 improvements are well-documented in AWS benchmarks. The 30% performance improvement reflects throughput measured in transactions per second (TPS) on standard OLTP benchmark workloads.

A throughput gain is not numerically identical to a cost-per-work reduction. At the same hourly price, 30% more throughput means 30% more throughput per dollar, or 23.1% less cost per unit of work if fully utilized. With the checked r7g/r6g large prices ($0.239/$0.225), a hypothetical 30% throughput gain would mean about 22.4% more throughput per dollar. Use the exact benchmark workload and pricing basis for any quoted percentage.

The DDR5 memory in Graviton3 contributes meaningfully for PostgreSQL workloads where the shared_buffers or working set exceeds the CPU’s cache. DDR5’s 50% higher memory bandwidth versus DDR4 reduces the time a CPU core spends waiting for memory reads, which is a primary bottleneck for large PostgreSQL buffer pool operations.

Graviton4 vs Graviton3: measured PostgreSQL benchmark results

The AWS Database Blog benchmark published June 27, 2025 tested PostgreSQL 16.3 with Sysbench OLTP read/write on db.m6g.xlarge, db.m7g.xlarge, and db.m8g.xlarge in US East (N. Virginia), using Single-AZ instances and io2 storage. In that setup, m8g delivered 23% more queries per second than m7g and 41% more than m6g. Its price-performance improvement versus m7g was 23% using the blog’s June 2025 price basis. These measured results are separate from the broader launch claims of up to 40% performance and up to 29% price-performance improvement; neither predicts every workload’s result.

For Aurora PostgreSQL specifically, the December 2025 AWS Database Blog post measured 1.7x write throughput improvement on r8g.16xlarge versus R6g (Graviton2) and 38% reduction in commit latency on r8g.2xlarge. These Aurora-specific numbers are higher than the RDS-only figures because Aurora’s storage layer is separately optimized. RDS PostgreSQL gains depend on the tested workload without the Aurora storage optimizations.

A Graviton3 pgvector benchmark cannot establish an identical gain for Graviton4. Test the actual PostgreSQL version, index, query mix and instance size before using a throughput percentage in a savings forecast.

Illustration only. The displayed instance types and figures are not the measured configuration or results in the AWS benchmark cited above.

The Compounding Saving: Graviton Migration Plus Reserved Instances

For an identical fully utilized Single-AZ deployment, db.r6i.xlarge On-Demand costs $0.500 × 8,760 = $4,380/year. Moving to db.r8g.xlarge at $0.478/hr costs $4,187.28/year, saving $192.72 (4.4%) before migration and other charges.

After confirming sizing, a one-year No Upfront r8g.xlarge RI at $0.320/hr costs $2,803.20/year. Compared with the original x86 On-Demand baseline, the combined saving is $1,576.80 per instance per year (36.0%), or $15,768/year for ten instances. This assumes full eligible use and no stranded earlier commitments. The commitment is payable even if unused.

If testing separately proves that r8g.large is sufficient, its $0.239/hr On-Demand cost is $2,093.64/year, saving $2,286.36/year against the original r6i.xlarge baseline. A claimed 40% performance gain alone does not justify halving resources: half the resources at 1.4× performance would provide only 70% of the former capacity under a simplistic linear model.

The checked catalog did not list a three-year All Upfront r8g.xlarge quote. Do not represent three repeated one-year costs as a locked three-year offer. Migrate and validate first; reservations do not transfer across the r6i, r7g and r8g families.

Which PostgreSQL Workloads Benefit Most From Graviton4

OLTP Workloads (Highest Benefit)

Standard web application databases with mixed read-write patterns benefit strongly from Graviton4. The reported “up to” throughput improvement must be validated on the actual workload before it is used in a cost forecast. For OLTP workloads where query latency is a key metric, the commit latency reduction (38% on r8g.2xlarge versus R6g in Aurora benchmarks) is meaningful for user-facing applications where database latency contributes to page load time or API response time.

pgvector and AI Workloads (Very High Benefit)

As covered in the previous blog in this series, pgvector HNSW similarity search benefits significantly from Graviton3 and further improvements on Graviton4. The hardware SIMD acceleration in Graviton4 specifically improves distance computation performance for vector similarity search. Teams running vector search workloads should prioritize Graviton4 R8g instances over x86 or earlier Graviton generations for both cost and performance reasons.

Analytics and Reporting Workloads (Moderate to High Benefit)

Complex analytical queries that scan large tables and perform aggregations are memory-bandwidth bound. Graviton4’s DDR5-5600 memory provides higher bandwidth than the DDR5-4800 in Graviton3 and the DDR4 in x86 and Graviton2 instances. For PostgreSQL workloads running large GROUP BY aggregations, window functions over large result sets, or sequential scans across large tables, the memory bandwidth improvement compounds with the core performance improvement.

Connection-Heavy Workloads (Moderate Benefit)

PostgreSQL process-per-connection architecture means that CPU overhead for connection establishment and session management scales with concurrent connection count. For databases running PgBouncer or handling high connection rates, Graviton4’s per-vCPU improvements reduce the CPU overhead per connection, freeing more cycles for actual query execution.

Write-Heavy OLTP With High Commit Rates (High Benefit for Durability Settings)

The commit latency reduction documented in the Aurora benchmark (46% on r8g.16xlarge) reflects Graviton4’s storage I/O path improvements. For RDS PostgreSQL (not Aurora), the improvement is attributable to the faster CPU completing the WAL write path more efficiently. For workloads with synchronous_commit = on (the default and recommended setting), reducing CPU overhead in the commit path directly reduces effective write latency.

The T4g Burstable Instance Trap

PostgreSQL db.t4g.large Single-AZ is $0.129/hr in the checked US East catalog; db.r8g.large is $0.239/hr. T4g is billed in Unlimited mode, with surplus CPU credits at $0.075/vCPU-hour when usage exceeds the applicable baseline over the rolling accounting window. RIs do not cover those charges.

A two-hour nightly burst at 100% CPU does not necessarily create an overage: earned credits and the other 22 hours matter. For example, an idle remainder of the day gives only 8.33% average utilization, below the 30% t4g.large baseline. The earlier $109.50/year surcharge assumed every busy CPU-hour was billable and was incorrect.

For a separate example of sustained 100% utilization with credit balance exhausted, two vCPUs above a 30% baseline generate 2 × (1 − 0.30) × $0.075 = $0.105/hour in surplus charges, or $76.65 per 730-hour month, in addition to $94.17 in instance charges. Monitor actual surplus credits and compare alternatives; a P95 threshold alone does not determine billing.

PostgreSQL Version Compatibility With Each Graviton Generation

All current Graviton generations support all current PostgreSQL major versions on RDS. There are no PostgreSQL version restrictions for Graviton3 or Graviton4 — if a PostgreSQL version is supported on RDS, it runs on all Graviton instance families.

PostgreSQL 13: standard support ended February 28, 2026 (per AWS Database Blog). Running PostgreSQL 13 on any instance class including Graviton4 now incurs Extended Support charges per vCPU-hour. Migrating to Graviton4 while simultaneously upgrading to PostgreSQL 16 eliminates Extended Support charges, reduces instance cost, and improves performance — three improvements from two planned changes.

PostgreSQL 14: standard support ends February 2027. Plan migration before that date to avoid Extended Support charges.

PostgreSQL 17: current major version, fully supported on all Graviton generations including Graviton4 R8g. Source: AWS official RDS PostgreSQL release notes and AWS Database Blog (February 2026).

Also read: RDS Extended Support Pricing: PostgreSQL version end-of-life costs 

How to Migrate From x86 to Graviton4: The Process

Step 1: Identify Eligible Instances With AWS Compute Optimizer

AWS Compute Optimizer analyzes your RDS instances and identifies specific Graviton migration recommendations including the projected savings and performance change. As of August 2025, Compute Optimizer provides database-specific Graviton recommendations with projected metric improvements (CPU, network throughput) for each instance. Source: AWS Database Blog (August 2025). Navigate to Compute Optimizer in the AWS console, select DB instances, and review Graviton recommendations for your PostgreSQL fleet.

Step 2: Test With a Non-Production Copy

Before migrating any production database: restore a snapshot of the production database to a Graviton4 instance in a development environment. Run your application’s benchmark or load test suite against the Graviton4 instance for 24-48 hours. Verify query performance, memory utilization, and connection handling. PostgreSQL is open-source and natively compiled for ARM64 — no application code changes are required and there are no known compatibility issues for standard PostgreSQL workloads.

Step 3: Modify the Production Instance

For Single-AZ instances: navigate to the RDS console, select the instance, click Modify, change the DB instance class to the target Graviton4 instance (db.r8g.xlarge, db.m8g.xlarge, etc.), and apply during the next maintenance window. The modification requires a database reboot.

For Multi-AZ instances: the modification process triggers a Multi-AZ failover. The standby is updated first, then a failover occurs, then the original primary is updated. Downtime is typically 60-90 seconds during the failover. For zero-downtime migrations, use Blue/Green deployment: create a Green (Graviton4) copy of the database, allow it to sync as a replica, verify performance, then perform a managed switchover.

Step 4: Verify and Monitor for 30 Days

After migration, compare CPUUtilization, DatabaseConnections, ReadIOPS, WriteIOPS, FreeableMemory, latency, throughput, and query plans under representative load. Validate service targets and capacity headroom. There is no fixed expected CPU percentage reduction: bottlenecks, configuration, storage, and query mix can change the result.

Step 5: Purchase the RI After Confirming Stability

After validating the Graviton4 instance and sizing over a representative operating period: compare currently offered Reserved Instances. For PostgreSQL, RIs are size-flexible — a db.r8g.xlarge RI covers 2x db.r8g.large or 0.5x db.r8g.2xlarge. Purchase Single-AZ RIs at the smallest confirmed instance size in the target family to maximize normalization unit flexibility. Check whether the desired term and payment option are listed; compare their total cost with realistic utilization and migration plans.

Reserved Instance Strategy for Graviton Instances

Size Flexibility Works the Same as All PostgreSQL RIs

PostgreSQL Reserved Instances on all Graviton generations are size-flexible. A db.r8g.xlarge RI (8 normalization units) can cover 2x db.r8g.large (4 units each), or 0.5x db.r8g.2xlarge (16 units), or any fractional combination within the r8g family. Size flexibility applies within a single generation and family — an r8g RI does not cover r7g instances, and an r7g RI does not cover r8g instances.

The Generation Boundary Rule

This is the most common RI mistake for teams migrating to Graviton4. An r7g RI purchased before migrating to r8g becomes stranded when the migration occurs. The r7g RI continues billing at the committed rate. The r8g instance bills at on-demand rates because no r8g RI matches it. Teams end up paying for both the r7g RI commitment and the r8g on-demand rate simultaneously.

The correct sequence: migrate to r8g first, confirm stability under representative load, then purchase r8g RIs. If you have active r7g RIs, do not migrate until they expire unless the total cost of double-billing for the remaining RI term is less than the total cost of staying on r7g for the term.

R8g vs R7g RI Discount Depth

Use the engine-specific quotes in the table above. For r8g.large, the one-year No Upfront discount is 33.1%; for r7g.large it is about 23.0%. This does not establish a three-year r8g All Upfront price: that quote was not listed in the checked catalog.

Payment Option Decision for PostgreSQL Graviton RIs

Compare total committed payments over the same term and include upfront fees. Choose only offerings actually available for the required family, engine, Region and deployment. Test expected utilization and resizing plans; a larger nominal discount can lose money when capacity is unused.

How Usage.ai Handles Graviton and RI Optimization Together

Usage.ai identifies RDS PostgreSQL instances running on x86 or earlier Graviton generations and surfaces Graviton4 migration recommendations with specific projected savings, validated against the 24-hour refresh of actual utilization data. The platform distinguishes between instances where the performance improvement from Graviton4 would allow right-sizing to a smaller instance class (capturing additional savings) and instances where the current size is already correct and the improvement goes purely to throughput headroom.

For RI purchasing, Usage.ai applies the generation boundary rule explicitly: it does not recommend purchasing an RI on any instance family where a Graviton migration is in the recommendation queue. The migration recommendation and the RI recommendation are sequenced correctly — migrate first, then reserve — preventing the double-billing trap that occurs when teams purchase RIs on x86 or R7g instances and then migrate to R8g without coordinating the two decisions.

For instances running PostgreSQL versions approaching end-of-standard-support, Usage.ai flags the version upgrade as a prerequisite to any 3-year RI purchase recommendation. A 3-year RI purchased on a database that enters Extended Support in year 2 of the term generates RI savings on compute while simultaneously accumulating Extended Support charges per vCPU-hour. The net saving is substantially lower than the RI discount implies.

For eligible Flex commitments, Cashback applies under the customer agreement when commitment costs exceed equivalent On-Demand costs for the same usage. It is not an automatic refund for every unused RI and does not cancel the AWS commitment. Review eligibility, fees, and payment timing in the applicable terms.

See exactly what you’re overpaying in under 60 seconds. Try the Calculator for free →

You’re Overpaying AWS. See by How Much in 60 Seconds.Upload your AWS bill and get your exact overspend number for free. No account access, or commitment required.FIND MY SAVINGS

Frequently Asked Questions

1. Is RDS PostgreSQL compatible with Graviton4?

Yes. All current PostgreSQL major versions (12, 13, 14, 15, 16, 17) supported on Amazon RDS run on Graviton4 db.r8g and db.m8g instances. PostgreSQL is open-source and natively compiled for ARM64 architecture. No application code changes, no driver updates, and no PostgreSQL configuration changes are required. The migration requires an instance type modification and a reboot or Multi-AZ failover. Source: AWS official RDS documentation.

2. How much faster is Graviton4 than Graviton3 on RDS PostgreSQL?

AWS’s June 27, 2025 PostgreSQL 16.3 Sysbench test found db.m8g.xlarge delivered 23% more queries per second than db.m7g.xlarge and 41% more than db.m6g.xlarge. Price-performance versus m7g improved 23% using that test’s June 2025 prices. These are workload-specific results, not a guaranteed improvement for your database; benchmark representative traffic before migrating.

3. How much does Graviton4 RDS cost versus x86?

In the checked US East Single-AZ PostgreSQL prices, r8g.xlarge is $0.478/hr versus $0.500/hr for r6i.xlarge: $192.72/year less at 8,760 hours. A one-year No Upfront r8g.xlarge RI is $0.320/hr, giving a combined $1,576.80/year saving against the original x86 On-Demand baseline at full use. A three-year All Upfront r8g quote was not listed.

4. Do Graviton4 Reserved Instances support size flexibility on PostgreSQL?

Yes. PostgreSQL Reserved Instances on db.r8g and db.m8g are size-flexible. One RI covers multiple sizes within the same family via normalization units. A db.r8g.xlarge RI (8 normalization units) covers 2x db.r8g.large (4 units each). This size flexibility applies only within the r8g family — an r8g RI does not cover r7g or r6g instances, and vice versa.

5. Can I use an existing Graviton3 RI on a Graviton4 instance?

No. An r7g (Graviton3) Reserved Instance does not cover db.r8g (Graviton4) instances. The generation boundary applies to all RDS RI families — r7g and r8g are separate families. Purchasing r7g RIs and then migrating to r8g results in double-billing: the r7g RI commitment continues billing while the r8g instance bills at on-demand rates. Always migrate to the target Graviton generation first, confirm stability under representative load, then purchase RIs on the new generation.

6. Should I use T4g for RDS PostgreSQL?

T4g can fit workloads with low average CPU and short bursts. Estimate paid surplus credits using the instance baseline and rolling credit accounting, not P95 alone. PostgreSQL surplus credits cost $0.075/vCPU-hour and are outside RI discounts. A short daily burst can be covered by credits earned during idle periods.

7. How long does the Graviton migration take?

For a Single-AZ instance: the instance modification (console or CLI) takes 5 minutes to initiate. Applying the change during a maintenance window causes a reboot of approximately 2-3 minutes. Total downtime: approximately 2-3 minutes. For a Multi-AZ instance using normal modification: a Multi-AZ failover occurs, causing approximately 60-90 seconds of downtime. For zero-downtime: use Blue/Green deployment, which creates a parallel Graviton4 copy, allows full synchronization, then performs a managed switchover with typically under 30 seconds of application impact.