RDS Optimized Reads: NVMe Cache for Read-Heavy Workloads (2026)

RDS Optimized Reads uses NVMe SSDs as a read-only cache to speed up database queries for read-heavy workloads.

Let’s see it in action. Imagine you’re running a popular e-commerce site, and your products table is massive. Queries like SELECT * FROM products WHERE category = 'electronics'; are hitting your database constantly. Without Optimized Reads, every single one of these would need to go all the way down to your primary storage (like EBS). This can be slow, especially if your data isn’t already in the database’s buffer pool.

With Optimized Reads, a portion of your frequently accessed data from the products table gets copied to a high-speed NVMe SSD. When that same query runs again, RDS checks the NVMe cache first. If the data is there (a cache hit), it serves the result directly from the NVMe, which is orders of magnitude faster than hitting EBS or even memory. This dramatically reduces latency for those repetitive, read-intensive queries.

Here’s the mental model:

• The Problem: Traditional databases, even with in-memory caches (buffer pools), can struggle with read-heavy workloads where data frequently accessed isn’t always in the buffer pool, or where the sheer volume of reads overwhelms the primary storage I/O.
• The Solution (Optimized Reads): Introduce a secondary, ultra-fast, read-only cache layer using NVMe SSDs. This layer sits between your application and your primary database storage.
• How it Works:
  • Write Path: Writes still go to your primary storage. Optimized Reads is a read cache; it doesn’t intercept writes.
  • Read Path: When a read query arrives:
    1. RDS checks its internal buffer pool (memory). If found, it’s served.
    2. If not in the buffer pool, RDS checks the NVMe cache. If found (cache hit), the data is served from NVMe, which is very fast.
    3. If not in the NVMe cache (cache miss), RDS fetches the data from primary storage (e.g., EBS).
    4. A copy of the data fetched from primary storage is then written to the NVMe cache.
    5. The data is served to the application.
• The Levers You Control:
  • Instance Type: Optimized Reads is available on specific instance families (e.g., r5, r6g, m5, m6g, x1, x1e, z1d and newer) and requires instances with local NVMe storage. You choose an instance type that supports it. For example, db.r6g.xlarge has local NVMe storage.
  • Cache Size: The amount of NVMe storage allocated for the cache is determined by the instance type. Larger instances get more NVMe cache. For instance, a db.r6g.xlarge might have 100 GiB of NVMe cache, while a db.r6g.8xlarge could have up to 700 GiB. You don’t provision the cache directly; it’s tied to the instance.
  • Database Engine & Version: Optimized Reads is supported for specific versions of PostgreSQL and MySQL. You need to ensure your RDS instance is running a compatible engine and version. For example, PostgreSQL 11.7+ or MySQL 5.7.27+.
  • Enabling: You enable Optimized Reads by selecting a supported instance class when creating or modifying an RDS DB instance. It’s not a separate feature to toggle on/off after instance creation; it’s part of the instance configuration.

The most surprising thing is how it handles data eviction. When the NVMe cache is full, RDS uses a Least Recently Used (LRU) algorithm, but it’s a smart LRU. It doesn’t just evict the oldest item; it prioritizes evicting blocks that have been read fewer times, aiming to keep the most frequently accessed data in the cache. This means even if a large block of data was initially read, if it’s not being hit repeatedly, it’s more likely to be replaced by newer, more actively queried data.

The next concept you’ll want to understand is how to monitor cache hit rates to determine its effectiveness.