In this post, we demonstrate how upgrading to Graviton4-based R8g instances with Aurora PostgreSQL-Compatible 17.4 on Aurora I/O-Optimized cluster configuration can deliver significant price-performance gains – delivering up to 1.7 times higher write throughput, 1.38 times better price-performance and reducing commit latency by up to 46% on r8g.16xlarge instances and 38% on r8g.2xlarge instances as compared to Graviton2-based R6g instances.
Amazon Aurora PostgreSQL-Compatible Edition now supports AWS Graviton4-based R8g instances and PostgreSQL major version 17, with compatibility up to PostgreSQL 17.4, which introduces key performance improvements for Amazon Aurora I/O-Optimized configurations. These enhancements optimize write operations through improved storage layer interactions and more efficient batch processing. Aurora I/O-Optimized cluster configurations provide predictable pricing and improved performance for I/O-intensive workloads, making it an ideal choice for applications requiring high throughput and low latency. To learn more, see New – Amazon Aurora I/O-Optimized Cluster Configuration with Up to 40% Cost Savings for I/O-Intensive Applications.
Graviton4-based R8g instances offer improved performance, scalability and better price-performance for memory-intensive workloads. R8g instances provide up to 192 vCPUs — three times more vCPUs than Graviton2-based R6g instances, and up to 1.5 TB of memory, also up to three times more memory than R6g instances. They feature an 8:1 memory-to-vCPU ratio and support larger instance sizes up to 48xlarge, making them ideal for large scale database deployments. Built on the AWS Nitro System, Graviton4-based R8g instances deliver up to 50 Gbps of network bandwidth, providing high throughput and low latency. Additionally, the R8g instances include the latest DDR5-5600 memory to optimize performance for databases, in-memory caching, and real-time analytics.
PostgreSQL 17 community updates add vacuum improvements that reduce memory usage, shorten vacuum completion time, and display index vacuuming progress. PostgreSQL 17 alleviates the need to drop logical replication slots during major version upgrades. It also expands SQL/JSON standards, introducing JSON_TABLE feature to convert JSON data into standard PostgreSQL tables. Additionally, PostgreSQL 17 enhances query performance and provides greater flexibility in partition management by allowing partitions to be split and merged.
Aurora PostgreSQL-Compatible separates compute from storage through its distributed storage architecture, enabling independent scaling while maintaining six-way replication for high durability. Unlike traditional PostgreSQL implementations that write data pages, the Aurora storage layer processes database changes as log records, significantly reducing I/O operations and improving performance. Aurora PostgreSQL-Compatible 17.4 introduces enhancements to the Aurora I/O-Optimized cluster configurations. These improvements include smart batching and optimized write operations, delivering more consistent performance and lower latency for write-intensive workloads. The latest performance improvements further optimize write operations by separating critical write paths from background maintenance activities. This separation enables faster and more consistent write completions, helping you achieve higher throughput and lower commit latency, which we discuss in the following sections.
How workloads benefit from the Graviton4-based R8g instances on Aurora PostgreSQL-Compatible 17.4
Graviton4-based R8g instances running PostgreSQL 17.4 enhance performance for a wide range of data-intensive applications across various industry verticals through significant improvements in write throughput and commit latency. For example:
- Online gaming services deliver real-time leaderboard updates and player statistics, enhancing user engagement
- Financial services applications execute high-frequency trading strategies and risk assessments faster
- Social media analytics engines capture emerging trends through instant processing of user interactions
- SaaS systems scale to support more concurrent users with higher performance and improved efficiency
- Generative AI applications using vector search capabilities, deliver faster hybrid/semantic search with expanded compute and DDR5 memory
- Startups access enterprise-grade database performance to rapidly prototype and scale innovative applications
- Healthcare systems process patient data and medical imaging in real time for faster diagnoses
These performance improvements enable businesses across industries to accelerate data-driven decisions and deliver more responsive services to their customers.
Aurora PostgreSQL-Compatible performance improvements
The Aurora I/O-Optimized cluster configuration offers enhanced price performance and predictable pricing for I/O-intensive workloads, including e-commerce services and payment processing systems. This configuration is designed to optimize both read and write operations, featuring Aurora Optimized Reads for accelerated read performance through improved buffer cache management, along with performance improvements that boost write throughput and reduce latency. To learn more about the capabilities of Optimized Reads, refer to New – Amazon Aurora Optimized Reads for Aurora PostgreSQL with up to 8x query latency improvement for I/O-intensive applications.
Aurora PostgreSQL-Compatible generates log records and send them in batches to the storage client process running on the DB instance. The storage client process dispatches these log record batches concurrently over the network to a set of six storage nodes across three availability zones, where they are written to local SSDs. Aurora PostgreSQL-Compatible requires a write quorum of four out of six storage nodes for durability. Aurora sends batches concurrently to multiple storage nodes without ordering (log sequence number) requirements, and the storage client process maintains transaction consistency by processing responses in log sequence number (LSN) order for successful commits.
Aurora PostgreSQL I/O-Optimized cluster configuration introduced smart batching to optimize database write operations. At its core, this feature uses an adaptive algorithm to dynamically adjust batch flush size and frequencies based on real-time storage performance feedback. The storage client process continuously monitors how quickly the distributed storage processes write batches and automatically optimizes batch sizes to minimize latency while maintaining efficient write throughput.
Aurora PostgreSQL-Compatible 17.4 brings additional write performance optimizations for Aurora I/O-Optimized clusters. This enhancement redesigns the database write path to Aurora storage for improved performance. The new improvements separate critical write operations from background maintenance activities, alleviating potential interference that previously caused write latency jitter. This separation makes sure critical write paths operate independently from background tasks. By maintaining distinct paths for these operations, Aurora I/O-Optimized cluster configuration on Aurora PostgreSQL-Compatible 17.4 delivers more consistent and faster write completions, improving both commit latency and write throughput.
Performance benchmark using HammerDB
For this benchmarking exercise, we used HammerDB which is an open-source benchmarking tool that simulates real-world OLTP workloads through TPC-C-like benchmarks, where multiple virtual users execute concurrent transactions mimicking a wholesale supplier’s operations (new orders, payments, stock updates, etc.) in a multi-threaded architecture, enabling accurate measurement of database performance, scalability, and transaction behavior using a configurable TPROC-C schema whose size is determined by the number of warehouses (pg_count_ware parameter) specified.
To illustrate, with 2,500 warehouses the number of rows for each table are as follows.
| Table | Rows per Warehouse | Total Rows for 2500 Warehouses |
| warehouse | 1 | 2,500 |
| district | 10 | 25,000 |
| customer | 30,000 | 75,000,000 |
| history | 30,000 | 75,000,000 |
| orders | 30,000 | 75,000,000 |
| new_order | 9,000 | 22,500,000 |
| order_line | 300,000 | 75,000,000 |
| stock | 100,000 | 25,000,000 |
| item | 100,000 | 100,000 (fixed) |
We used the following key HammerDB parameters in creating the TPROC-C schema and running the TPC-C workload:
- pg_count_ware – Number of warehouses to create in the database, determining the total database size and data distribution
- vu – Number of virtual users (concurrent connections) that will simultaneously execute transactions during the test
- pg_rampup – Initial warm-up period (in minutes) where transactions are executed but not counted in the final metrics
- pg_duration – Total duration of the test (in minutes) after ramp-up period where transactions are measured and counted
The following table summarizes the cluster and benchmark configurations.
| Cluster Setup Configuration | Benchmark Run Configuration (HammerDB v4.11) | ||||||
| Database Version | Instance Class | Instance Size | Workload Size | Warehouse (pg_count_ware) | Virtual Users (vu) | Ramp-up Time – mins (pg_rampup) | Duration – mins (pg_duration) |
| Aurora PostgreSQL 15.10 and 17.4; both using I/O-Optimized | R6g (Graviton2) and R8g (Graviton4) | 2xlarge | small | 400 | 128 | 5 | 25 |
| 16xlarge | medium | 2500 | 512 | 5 | 25 | ||
| 24xlarge | large | 3750 | 1024 | 5 | 25 | ||
HammerDB’s standard performance metrics include transactions per minute (TPM) and new orders per minute (NOPM). TPM measures overall transaction throughput, encompassing both commits and rollbacks, and NOPM specifically tracks successful “new order” transactions, providing a precise indicator of useful database throughput that mirrors real-world database performance.
We focus on comparing performance improvements using the NOPM metric from HammerDB and the CommitLatency metric from Amazon CloudWatch. The NOPM metric offers a clear view of successful transactional throughput, and the CommitLatency metric from CloudWatch provides critical insights into the average time taken for transaction commits, directly reflecting the efficiency of Aurora PostgreSQL in handling transactional workloads. A higher NOPM value indicates better overall system performance for high-throughput workloads and a lower CommitLatency value generally indicates better write performance and system responsiveness. Together, these metrics enable a comprehensive assessment of the performance improvements made in Aurora PostgreSQL-Compatible 17.4 on Graviton4.
Performance improvements with Graviton4-based R8g instances on Aurora PostgreSQL version 17.4
In this section, we demonstrate the performance improvements with Graviton4-based R8g instances on Aurora PostgreSQL-Compatible 17.4 with three separate use cases. And as outlined in the benchmark configuration table above, we ran tests across different workload sizes (small, medium, large), each with their corresponding warehouse counts and virtual user configurations.
Use case 1: Hardware upgrade from Graviton2 to Graviton4
This use case demonstrates the performance benefits you can get from upgrading the hardware from Graviton2-based R6g instances to the new Graviton4-based R8g instances while maintaining the same Aurora PostgreSQL-Compatible database engine version (for this benchmark, PostgreSQL 15.10). This hardware upgrade delivers substantial performance improvements, making it an attractive option for enhancing database capabilities with no code changes required.
For small workloads on 2xlarge instance size:
- Throughput increased by 50.25%
- Commit latency improved by 33.87%
| Metric Name | r6g.2xlarge PostgreSQL 15.10 Graviton2-based | r8g.2xlarge PostgreSQL 15.10 Graviton4-based | Gain |
| Throughput (NOPM) | 119,104 | 178,950 | 1.5x |
| Commit Latency (milliseconds) | 18.6 | 12.3 | 1.3x |
For medium workloads on 16xlarge instance size:
- Throughput increased by 30%
- Commit latency improved by 17.44%
| Metric Name | r6g.16xlarge PostgreSQL 15.10 Graviton2-based | r8g.16xlarge PostgreSQL 15.10 Graviton4-based | Gain |
| Throughput (NOPM) | 628,014 | 816,134 | 1.3x |
| Commit Latency (milliseconds) | 19.5 | 16.1 | 1.17x |
The following chart shows a notable increase in performance when upgrading from R6g to R8g instances. For medium workloads, the upgrade provides enhanced throughput and reduced commit latency. Similarly, for small workloads, the upgrade results in improved performance metrics.
Use case 2: Database engine version upgrade from PostgreSQL 15.10 to 17.4 on Graviton4
Upgrading the database engine version from Aurora PostgreSQL-Compatible 15.10 to 17.4 on Graviton4-based R8g instances demonstrates the impact of the new improvements in Aurora PostgreSQL-Compatible. These improvements optimize write operations, reduce commit latency, and increase throughput, providing an option for customers that are already on Graviton4-based R8g instances to perform the upgrade.
For small workloads on 2xlarge instance size:
- Throughput increased by 15%
- Commit latency improved by 7.32%
| Metric Name | r8g.2xlarge PostgreSQL 15.10 | r8g.2xlarge PostgreSQL 17.4 | Gain |
| Throughput (NOPM) | 178,950 | 204,946 | 1.15x |
| Commit Latency (milliseconds) | 12.3 | 11.4 | 1.07x |
For medium workloads on 16xlarge instance size:
- Throughput increased by 30%
- Commit latency improved by 35.40%
| Metric Name | r8g.16xlarge PostgreSQL 15.10 | r8g.16xlarge PostgreSQL 17.4 | Gain |
| Throughput (NOPM) | 816,134 | 1,077,440 | 1.3x |
| Commit Latency (milliseconds) | 16.1 | 10.4 | 1.35x |
For large workloads on 24xlarge instance size:
- Throughput increased by 40%
- Commit latency improved by 39%
| Metric Name | r8g.24xlarge PostgreSQL 15.10 | r8g.24xlarge PostgreSQL 17.4 | Gain |
| Throughput (NOPM) | 930,606 | 1,236,904 | 1.4x |
| Commit Latency (milliseconds) | 28.8 | 17.6 | 1.39x |
The following chart shows the scalability of the latest improvements with the separation of critical write paths from background maintenance activities, leading to faster write operations and improved overall performance. These enhancements, when combined with the powerful Graviton4-based R8g instances, deliver significant performance improvements across workload sizes.
Use case 3: Combined hardware and database engine version upgrade
The most significant performance benefits are achieved by combining the hardware upgrade from Graviton2-based R6g to Graviton4-based R8g instances with the database engine version upgrade from Aurora PostgreSQL-Compatible 15.10 to 17.4. This dual upgrade approach provides optimal performance, reduced commit latency, and the best price-performance ratio for various workload sizes.
For small workloads on 2xlarge instance size:
- Throughput increased by 70%
- Commit latency improved by 38.71%
| Metric Name | r6g.2xlarge PostgreSQL 15.10 Graviton2-based | r8g.2xlarge PostgreSQL 17.4 Graviton4-based | Gain |
| Throughput (NOPM) | 119,104 | 204,946 | 1.7x |
| Commit Latency (milliseconds) | 18.6 | 11.4 | 1.38x |
For medium workloads on 16xlarge instance size:
- Throughput increased by 70%
- Commit latency improved by 46.67%
| Metric Name | r6g.16xlarge PostgreSQL 15.10 Graviton2-based | r8g.16xlarge PostgreSQL 17.4 Graviton4-based | Gain |
| Throughput (NOPM) | 628,014 | 1,077,440 | 1.7x |
| Commit Latency (milliseconds) | 19.5 | 10.4 | 1.46x |
The following chart shows that the combined upgrade from Graviton2-based R6g instances to Graviton4-based R8g instances, along with the Aurora PostgreSQL-Compatible version upgrade from 15.10 to 17.4, delivers the most significant performance benefits.
Improved price performance and price-performance ratio
With the observed performance benefits, we looked at the cost efficiency of moving to a Graviton4-based R8g instances using two key metrics: price performance and price-performance ratio.
The price performance metric indicates how much you spend for each unit of performance (in terms of throughput or transactions), typically expressed as cost per million operations. A lower price performance value signifies better efficiency, as it means you achieve more work for less cost.
The price-performance ratio metric indicates how much performance (in terms of throughput and latency) you get for each dollar spent. A higher price-performance ratio means you can achieve better performance and throughput while paying a lower cost per unit of performance.
This is particularly important if you want to optimize your database performance without significantly increasing your operational costs.
By understanding both metrics, you can make informed decisions about which instances offer the best value for your specific workloads. These metrics help you evaluate the cost efficiency of different instance types and configurations, allowing you to decide whether to upgrade your hardware, your database engine, or both.
In this section, we explore how the combination of Graviton4-based R8g instances and the latest Aurora PostgreSQL-Compatible version delivers significant gains in both price performance and price-performance ratio. To illustrate, let’s consider the medium-sized workload on db.r6g.16xlarge (Graviton2) and db.r8g.16xlarge (Graviton4) instances in the US East (N. Virginia) Region.
db.r6g.16xlarge instance using Graviton2:
- Price per hour (USD) for On-Demand Instance: $10.798 for I/O-Optimized
- Throughput (NOPM) for 25-minute run: 628,014
Cost for 25-minute run:
$10.798/hour * (25/60) hours = $4.4992
Price Performance:
$4.4992 / 628,014 NOPM = $0.00000716 per NOPM
= $7.16 per million NOPM
Price-Performance Ratio:
628,014 NOPM / $4.4992 = 139,583 NOPM/$
db.r8g.16xlarge instance using Graviton4:
- Price per hour (USD) for On-Demand Instance: $11.488 for I/O-Optimized
- Throughput (NOPM) for 25-minute run: 1,077,440
Cost for 25-minute run:
$11.488/hour * (25/60) hours = $4.7867
Price Performance:
$4.7867 / 1,077,440 NOPM = $0.00000444 per NOPM
= $4.44 per million NOPM
Price-Performance Ratio:
1,077,440 NOPM / $4.7867 = 225,091 NOPM/$
| Metric | r6g.16xlarge (Graviton2) | r8g.16xlarge (Graviton4) | Improvement |
| On-Demand Instance Price for I/O Optimized ($/hour) | 10.798 | 11.488 | N/A |
| Run Duration (minutes) | 25 | 25 | N/A |
| Cost for Run ($) | 4.4992 | 4.7867 | N/A |
| Throughput (NOPM) | 628,014 | 1,077,440 | 1.7x |
| Price Performance ($/million NOPM) | 7.16 | 4.44 | 1.38x |
| Price-Performance Ratio (NOPM/$) | 139,583 | 225,091 | 1.61x |
A 61.26% improvement in the price-performance ratio shows that you can process significantly more transactions per dollar spent and the price performance metric shows a 38% improvement, decreasing from $7.16 to $4.44 per million NOPM, demonstrating lower cost per unit of performance when upgrading to db.r8g.16xlarge instances.
You can explore additional cost-optimization opportunities with the introduction of Reserved Instances for Graviton4-based R8g instances on a one-year term with Aurora PostgreSQL. Reserved Instances for Amazon Aurora offer savings over On-Demand instance rates with three flexible payment options: All Upfront, Partial Upfront, and No Upfront.
Conclusion
In this post, we discussed how the combined upgrade to Graviton4-based R8g instances and Aurora PostgreSQL-Compatible 17.4 provides the most significant benefits for write-intensive workloads. The performance improvements in Aurora PostgreSQL-Compatible 17.4, coupled with the advanced capabilities of Graviton4, provide higher throughput, reduced commit latency, and better price-performance that delivers consistent performance improvements across workload sizes. The combined upgrade approach takes advantage of the full potential of the database and allows organizations to deliver more responsive services to their customers.
If a combined upgrade is not feasible, a phased approach should be considered, starting with a hardware upgrade to Graviton4-based R8g instance for immediate throughput gains, followed by a database engine version upgrade to Aurora PostgreSQL-Compatible 17.4 for more consistent and faster performance for write-intensive workloads.
About the Authors
Rinisha Marar is a Database Specialist Solutions Architect at AWS with deep expertise in Amazon RDS and Amazon Aurora. She brings extensive experience in relational database technologies. Through architectural guidance and technical expertise, Rinisha helps organizations through complex database migrations, performance tuning, and the adoption of cutting-edge features. She is passionate about enabling customers to build resilient, scalable database solutions while following AWS best practices.
Jason Pedreza is a Senior Database Specialist Solutions Architect at AWS who specializes in orchestrating large-scale data transformations and migrations for petabyte-scale environments. His deep expertise in Amazon RDS and Amazon Aurora enables him to help organizations design and implement robust, enterprise-grade database solutions that optimize performance, scalability, and cost-efficiency. Jason partners with customers to architect highly available database solutions, leveraging his extensive knowledge of relational databases, data warehousing, data analytics, and cloud-based technologies.
Sunil Kamath is the head of engineering for Amazon Aurora database performance and PostgreSQL engine development. His team drives the performance and scalability charter of Amazon Aurora database and also Aurora PostgreSQL serverless and engine features. Sunil has over 24 years of experience in databases and has previously worked at Microsoft and IBM. He earned an MS in Computer Science at the University of Alberta, Canada.
Sharath Sulochana is an experienced performance engineer with over 17 years of experience in performance optimization and scalability of distributed systems. He has worked on end-to-end performance engineering by building infrastructure to enable benchmarking, reporting, analysis and optimization. For the last decade, he has worked extensively on relational and non-relational databases, currently leading Amazon Aurora PostgreSQL performance engineering efforts in AWS.
Source: Read More
