.png)
RDS Optimized Reads uses local NVMe in two ways. RDS engines and Aurora PostgreSQL Standard use it for temporary objects. Aurora PostgreSQL I/O-Optimized can also use it as a tiered database-page cache. There is no separate feature fee, but the required configuration can change total cost. Benchmark performance and the complete bill before committing.
Key takeaways
What RDS Optimized Reads does
| Deployment | How NVMe is used | Workloads most likely to benefit |
|---|---|---|
| RDS MySQL, MariaDB, and PostgreSQL | Temporary objects and files | Queries that spill substantial intermediate data to disk |
| Aurora PostgreSQL Standard | Temporary objects | Large sorts, joins, aggregations, reporting, and index operations that exceed working memory |
| Aurora PostgreSQL I/O-Optimized | Temporary objects plus tiered database-page cache | Temporary file-heavy queries and read-heavy workloads whose working set exceeds memory |
Engine differences that matter
| Database engine | Main NVMe use | AWS published benchmark result | Important condition |
|---|---|---|---|
| RDS for MySQL | Temporary objects and files | Up to 2× faster query processing | MySQL 8.0.28 or later on a supported class |
| RDS for MariaDB | Temporary objects and files | Up to 2× faster complex queries | Supported engine version and class required |
| RDS for PostgreSQL | Temporary tables and files | Up to 50% faster query processing | Supported PostgreSQL version and class required |
| Aurora PostgreSQL Standard | Temporary objects | Up to 2× better latency and throughput for qualifying advanced queries | Supported NVMe class and engine version |
| Aurora PostgreSQL I/O-Optimized | Temporary objects plus tiered cache | Up to 8× better latency for qualifying reads | Tiered cache is available only with I/O-Optimized |
These AWS benchmark results are not guarantees or fixed limits. Results depend on query plans, concurrency, data size, memory, cache state, engine version, and instance class.
Support varies by engine, version, class, and Region. Confirm the proposed NVMe-backed class in current AWS documentation.
What Optimized Reads costs
AWS charges no separate Optimized Reads feature fee. The NVMe hardware is included in the supported instance class, so the total price can still differ from a similar non-NVMe class.
For ordinary RDS, start with:
Aurora Standard versus I/O-Optimized ROI
Aurora tiered cache requires I/O-Optimized, so a simple instance-price comparison is insufficient. Calculate both configurations across every writer and reader:
In AWS’s US East (N. Virginia) example, a 1,000 GB database grows 20 GB daily, reads 350 pages per second, and writes 100. Standard storage and I/O total $362.28. I/O-Optimized storage totals $290.25, 19.8% less in this example.
The example excludes compute. Add the I/O-Optimized rate for every writer and reader, then apply eligible discounts. Use current Region-specific prices.
Aurora Standard versus I/O-Optimized ROI
Temporary-object mode is a strong candidate when execution plans spill substantial data beyond memory. This may occur during large sorts, joins, aggregations, CTEs, reports, CREATE INDEX, or REINDEX. Confirm actual temporary-file activity.
Aurora tiered cache can help point reads, indexed OLTP queries, and dashboards when active data exceeds RAM. It is less useful when data fits in memory or cache-hit ratio remains low.
Also compare Optimized Reads against query tuning, better indexes, and increased working memory.
These are not merely different interfaces around the same engine. One product makes a financial protection mechanism central to the offer; the other emphasizes continuous management of the customer’s native commitment portfolio.
Configuration and failure behavior
For PostgreSQL, review work_mem, maintenance_work_mem, temp_file_limit, and temp_tablespaces. On RDS for PostgreSQL, a session can redirect temporary work to EBS with SET temp_tablespaces TO ‘pg_default’; when local NVMe is insufficient.
For MySQL and MariaDB, review binlog_cache_size, temptable_max_mmap, and transaction size. Binary-log cache files can consume instance-store capacity. Avoid very large transactions and add retry logic for local-storage-full failures.
If NVMe fills, queries or transactions can fail. Test failure handling and keep adequate capacity.
For supported Aurora PostgreSQL versions, aurora_temp_space_size adjusts the temporary-space and cache split. By default, Aurora allocates twice instance memory to temporary objects, about 10% to internal operations, and the rest to cache.
Switching an NVMe-backed Aurora cluster between Standard and I/O-Optimized causes an immediate engine restart, and Aurora Standard can be changed to I/O-Optimized only once every 30 days.
The practical test:
Restore the same snapshot to comparable NVMe and non-NVMe environments. Keep the engine version, vCPU, memory, architecture, parameters, storage, dataset, concurrency, and query mix consistent. Run repeated cold-cache and warm-cache tests. Compare p50, p95 and p99 latency, throughput, error rate, temporary-file activity, cache-hit ratio, free-NVMe headroom, storage I/O, and total cost. Confirm that queries actually spill to NVMe or hit Aurora tiered cache. Also test failover and local-storage exhaustion before committing.
How to evaluate Optimized Reads
- Record the baseline. Capture p50, p95 and p99 latency, throughput, errors, CPU, memory, I/O, and cost.
- Find qualifying behavior. Verify that queries spill temporary data or, for Aurora, miss memory and hit tiered cache.
- Check compatibility. Confirm engine, Region, class, deployment, parameters, restart requirements, and maintenance impact.
- Benchmark a safe copy. Keep engine, architecture, vCPU, memory, parameters, storage, data, concurrency, and queries comparable.
- Repeat tests. Include warm cache, cold cache, failover, and local-storage-exhaustion scenarios.
- Calculate net value. Include every instance, storage, I/O, Multi-AZ, monitoring, licensing, migration, and discounts.
- Roll out and monitor. Use a maintenance window and verify performance, errors, failover behavior, and NVMe headroom.
Monitor regular RDS
Use FreeLocalStorage, FreeLocalStoragePercent, and local read/write IOPS, latency, and throughput. PostgreSQL users can also review temp_bytes, temp_files, IO:BufFileRead, and IO:BufFileWrite. See the RDS performance monitoring guide.
Monitor Aurora PostgreSQL
Purchase checklist
After validation, review the RDS Reserved Instance guide, RDS RI pricing, and Database Savings Plans guide. RI size flexibility stays within the same class type, so an r6g reservation does not cover r6gd usage. Compare both commitment options.
Disclosure: Usage.ai provides cloud cost optimization and commitment management services. Performance and savings depend on workload behavior, AWS pricing, eligibility, contract terms, and implementation. AWS benchmark figures and illustrative calculations in this article are not guarantees.
Frequently asked questions
Is RDS Optimized Reads free?
There is no separate feature fee. You still pay for the NVMe-backed class and, for Aurora tiered cache, I/O-Optimized. Compare the complete bill.
Does Optimized Reads replace durable storage?
No. Durable data, logs, snapshots, and backups remain on managed storage. Ephemeral NVMe holds temporary objects or eligible cached pages.
Which queries benefit most?
In temporary-object mode, the strongest candidates are queries that spill substantial intermediate data to disk. Aurora tiered cache can also benefit point reads and indexed transactions when the working set exceeds memory and requested pages hit the NVMe cache.
How much faster will my database be?
There is no guarantee. Results depend on query plans, data size, concurrency, memory, cache state, engine version, and instance class.
Should I purchase an RI or Database Savings Plan?
Only after validating the configuration. RDS RIs can provide deeper discounts for stable, matching usage, while Database Savings Plans provide broader flexibility across eligible engines, families, deployment options, and Regions. Compare both against On-Demand pricing and do not assume one commitment can discount the same usage twice.
