A quick RDS storage tweak for your Laravel app

Save money and get faster queries with one change

Joel Clermont

2026-03-12

Following up on Tuesday's tip about MySQL defaults, I wanted to share another practical performance change you can make on the infrastructure side if you are using Amazon RDS.

AWS regularly upgrades their storage offerings, and newer generations tend to be both faster and cheaper. RDS storage is a good example of this pattern.

With gp2, your performance is tied to volume size. You get 3 IOPS per GB of storage, so a 100 GB volume only gets 300 baseline IOPS. Small volumes can burst up to 3,000 IOPS temporarily, but once your burst credits run out, you're stuck at that low baseline. The only way to get more consistent performance is to buy a bigger disk, even if you don't need the space.

gp3 flips this around. Every volume starts with 3,000 IOPS and 125 MB/s throughput regardless of size. You can scale IOPS and throughput independently, so you pay for performance and storage separately. On top of that, gp3 is typically 20% cheaper per GB.

One thing to be aware of: if you have a very large gp2 volume (say 2 TB or more), the 3 IOPS/GB formula might already be giving you more than 3,000 baseline IOPS. In that case, switching to gp3 means you would need to explicitly provision those higher IOPS, which could offset some of the savings. For most Laravel apps though, this is not a concern.

For a small Laravel app, a sensible starting point is 20-40 GB of gp3 storage with 3000 IOPS. That gives you fast bursts for common read/write patterns without paying for oversized disks.

The best part is you can do this with minimal downtime. RDS handles the change online for most cases, so you can run it during off-peak hours without a maintenance window.

Here's the basic flow:

First, check your current settings:

aws rds describe-db-instances \
  --db-instance-identifier <DB_ID> \
  --query "DBInstances[0].{Storage:AllocatedStorage,Type:StorageType,IOPS:Iops}"

Then modify to gp3:

aws rds modify-db-instance \
  --db-instance-identifier <DB_ID> \
  --storage-type gp3 \
  --allocated-storage 40 \
  --iops 3000 \
  --apply-immediately

After the change, keep an eye on CloudWatch for a few hours. Watch ReadLatency, WriteLatency, and CPUUtilization under your normal traffic.

If latency spikes, you can bump IOPS in increments of 1000 and re-test. If things look over-provisioned, drop IOPS in steps of 500-1000 and watch the effect.

One caveat: if your current storage is over 100 GB, you can only shrink by doing a snapshot and restore. Otherwise, the type change happens in place.

Here to help,

Joel

P.S. Infrastructure changes can feel risky, especially on a production database. If you'd rather have someone walk through it with you, schedule a call and we'll help you get it right the first time.

Previous tip