Your AWS RDS bill just crossed $4,300 this month.
Your Black Friday traffic spiked 6x. Your product page load times ballooned to 8.4 seconds. And your DBA is still blaming "traffic." That is not a traffic problem. That is a database architecture problem. And it has been hiding in plain sight.
Typical outcome after optimization: $1,400-$2,800/month saved. Checkout queries drop from 4.2s to under 900ms.
We have deployed and optimized AWS RDS for e-commerce brands scaling from $500K to $15M ARR across the US, and the same four or five mistakes show up every single time. Here is what we found, what it costs you, and exactly how to fix it.
Your RDS Is Running on the Wrong Gear
Most e-commerce teams spin up a db.r6i.large because it was in a tutorial somewhere in 2021. Nobody revisits it. Nobody benchmarks it.
Here is what that costs you: AWS's M7i and R7i instance families now deliver up to 55% lower price than equivalent sixth-generation instances. If you are paying $2,200/month on an older instance class, you are burning roughly $1,210/month in avoidable compute costs. Over 12 months, that is $14,520 thrown away for no performance gain.
The Instance Class Tax
55%
Lower price on M7i/R7i vs sixth-generation instances
18-23%
Less per vCPU hour on Graviton (db.r7g, db.m7g)
$14,520
Thrown away annually by staying on older instance classes
Frankly, if you are not on Graviton-based instances (db.r7g, db.m7g) for MySQL, PostgreSQL, or MariaDB, you are paying the x86 premium for zero functional difference. AWS RDS users cannot touch the OS layer anyway — the microarchitecture is invisible to your database engine. Switch to Graviton. It runs the same queries faster and costs less.
(Yes, Graviton does not support MS SQL or Oracle. If you are on SQL Server for an e-commerce store in 2026, we need to have a different conversation entirely.)
The Read Traffic Problem Nobody Talks About
Here is the ugly truth about e-commerce database traffic: 87% of database queries on a typical product catalog are reads. Product listings, search filters, SKU lookups, cart validations — all reads. But 90% of the teams we audit are routing all of that directly to their primary RDS instance.
When a flash sale hits and 4,000 users simultaneously load your product pages, your primary instance chokes. Writes back up. Orders fail silently. Customers do not retry. They go to your competitor.
Layer 1: Read Replicas
RDS Read Replicas let you elastically scale out read traffic across multiple read-only instances. You can create up to 15 replicas for RDS MySQL and MariaDB.
For a db.r7g.2xlarge setup serving a $3M ARR Shopify store, adding two read replicas typically drops primary CPU utilization from 78% to under 31% during peak hours.
Layer 2: ElastiCache for Redis
Read replicas still replicate the full database. ElastiCache does not. You only cache query results, not the entire dataset. AWS benchmarks show that replacing multiple read replicas with an ElastiCache cluster delivers comparable read capacity at lower cost and sub-millisecond latency.
For product catalog queries that return the same data 10,000 times per hour, cache hit rates above 89% are achievable within the first two weeks of tuning.
Do not use both blindly. We see teams running three read replicas and ElastiCache simultaneously, paying double for redundant coverage. Pick the architecture that fits your read pattern. Static catalog data? Cache-first. User-specific order history? Replica-first.
The Slow Query That Is Killing Your Checkout
RDS ships with long_query_time set to 10 seconds by default. That means any query taking 9.9 seconds does not even get logged. For an e-commerce checkout flow where a 3-second response triggers cart abandonment, this default is a blind spot the size of your entire conversion funnel.
We drop long_query_time to 1.5 seconds on every e-commerce RDS deployment we touch. Immediately, slow query logs light up with queries nobody knew were slow.
The Most Common Offenders We Find
▸ Un-indexed product_id joins on the order_items table — adds 1.8-4.3 seconds per checkout query on stores with 500K+ SKUs
▸ Missing composite indexes on (user_id, created_at) for order history lookups
▸ SELECT * queries hitting the inventory table on every cart page load
One WooCommerce client had a single un-indexed category_id query adding 2.7 seconds to every category page load. Fixing that index took 4 minutes. It recovered $6,800/month in revenue from users who had been bouncing off slow pages.
Use Amazon RDS Performance Insights to identify the top SQL queries by load. It shows you load by waits, waits by query, and query history — everything your DBA needs to prioritize fixes without guessing.
Your Storage Type Is Throttling Your IOPS
Most e-commerce databases on RDS default to gp2 storage because it is familiar. gp2 gives you a baseline of 3 IOPS per GB. A 200 GB database gets 600 IOPS. During a flash sale, your e-commerce database needs 3,000-8,000 IOPS. You are throttled from the first spike.
Storage Type Comparison
gp2 (Default)
3 IOPS per GB. Locked to storage size. A 200 GB DB = 600 IOPS. Throttled from the first spike.
gp3 (Recommended)
Decoupled IOPS from storage. Provision 6,000 IOPS on a 20 GB database. ~$0.115/GB/month.
io2 Block Express
256,000 IOPS. Single-digit microsecond latency. For marketplaces with 1M+ daily orders.
For most e-commerce stores under $10M ARR, gp3 at 6,000 IOPS hits the sweet spot. If you are running a marketplace with 1M+ daily orders, io2 Block Express is the correct choice — the $180/month difference in storage cost is irrelevant compared to the revenue impact of a 200ms checkout improvement.
Multi-AZ Is Not Optional. Neither Is Your Backup Window.
We see this monthly: a US-based e-commerce client disables Multi-AZ to save $400/month. Then their primary RDS instance in us-east-1a has a disk failure at 11:47 PM on a Thursday. Their site is down for 43 minutes. At $12,000/hour in revenue, that is a $8,600 outage to save $400.
Multi-AZ keeps a synchronous standby replica in a different Availability Zone. Failover happens automatically in 60-120 seconds. Enable it. The cost is exactly double your instance price — but downtime costs 10-30x more.
The Backup Window Flaw
Set your automated backup window to 2:00 AM - 4:00 AM local time, not the AWS default of whatever-time-you-created-the-instance.
Why this matters:
Backup I/O spikes degrade performance by 15-22%. We have seen clients wonder why their 3 PM checkout is slow — the backup window was 2 PM - 4 PM because nobody changed the default.
What Aurora Gives You That Standard RDS Does Not
Aurora is not "just RDS with a different label." Aurora's storage layer automatically scales from 10 GB to 128 TiB in 10 GB increments without downtime. Aurora Serverless v2 scales compute in increments of 0.5 ACUs — it can go from 0.5 ACUs at 3 AM to 128 ACUs during a product drop and back down, billing only for what it uses.
For e-commerce brands with predictable weekday traffic and massive weekend spikes, Aurora Serverless v2 typically runs 31-44% cheaper than a fixed-instance RDS setup sized for peak load. One $4.2M ARR US apparel brand we migrated dropped their monthly RDS bill from $3,100 to $1,890 by switching to Aurora Serverless v2 — without changing a single line of application code.
The controversial opinion nobody will say out loud: Standard RDS is the wrong choice for most e-commerce workloads above $1M ARR. It is priced for steady-state workloads. E-commerce is inherently spiky. Aurora aligns cost with actual demand.
The Implementation Reality
Here is what a proper AWS RDS optimization engagement actually looks like — no magic, just sequence:
| Week | What Happens |
|---|---|
| Week 1 | Performance Insights audit. Identify top 10 slow queries. Fix indexes. Drop long_query_time to 1.5 seconds. |
| Week 2 | Migrate storage from gp2 to gp3. Set IOPS to 6,000. Validate with load testing. |
| Week 3 | Deploy ElastiCache for Redis. Implement query result caching for product catalog and session data. |
| Week 4 | Enable Read Replicas. Route read traffic. Right-size primary instance (r6i to r7g saves 22-28%). |
| Week 5-6 | Evaluate Aurora migration. Run cost model. Execute if justified. |
Typical outcome for a $2M-$8M ARR US e-commerce brand: $1,400-$2,800/month in AWS cost reduction and checkout query times dropping from 4.2 seconds to under 900ms.
Frequently Asked Questions
How many RDS Read Replicas does an e-commerce store need?
Most stores under $5M ARR need exactly one read replica routed through RDS Proxy. Stores doing $5M-$15M ARR typically need two, paired with ElastiCache. Beyond that, Aurora with its cluster endpoint handles read scaling better than stacking replicas.
Does switching to Aurora require rewriting code?
No. Aurora is MySQL- and PostgreSQL-compatible. Your existing queries, ORM configuration, and connection strings work without modification. The only change is the endpoint URL in your environment variables.
What is the fastest RDS optimization with immediate impact?
Lowering long_query_time to 1.5 seconds and running Performance Insights for 48 hours. This surfaces the exact queries causing slowdowns. Fixing the top three slow queries alone cuts average query time by 40-60% for most e-commerce databases.
Is Multi-AZ worth the cost for a small e-commerce store?
Yes, if you are doing more than $50,000/month in revenue. A single unplanned 30-minute outage during peak hours can cost more than 6 months of Multi-AZ fees. It is not optional at any meaningful revenue level.
How does ElastiCache reduce RDS costs?
ElastiCache caches query results in memory, so repeated reads (product listings, category pages) never hit the database. This lets you run a smaller RDS primary instance and fewer read replicas, directly cutting your monthly compute bill — often by $600-$1,500/month for mid-size stores.
Stop Letting a Misconfigured Database Kill Your Conversion Rate
A default gp2 volume and a backup window set to 2 PM are quietly bleeding your checkout performance right now. We will find your biggest RDS leak in the first call.
Free audit. Top slow queries identified. Cost savings estimate on the first call.