How to Scale PostgreSQL on AWS RDS: A Practical Guide to Vertical and Horizontal Scaling

When I first started deploying databases on AWS, I thought ‘scaling’ just meant clicking a button to get a bigger machine. But as my projects grew, I realized that knowing how to scale PostgreSQL on AWS RDS is less about the button and more about understanding the tradeoff between compute, memory, and I/O throughput.

Whether you’re hitting CPU ceilings during peak traffic or your queries are slowing down due to massive table growth, AWS provides several levers you can pull. In this guide, I’ll walk you through the exact steps I use to scale my production databases without causing unnecessary downtime.

Prerequisites

• An active AWS account with an existing PostgreSQL RDS instance.
• Basic familiarity with the AWS Management Console.
• A backup of your data (RDS snapshots are highly recommended before scaling).
• Knowledge of your current bottleneck (CPU, RAM, or Disk I/O) via Amazon CloudWatch.

Step 1: Vertical Scaling (Scaling Up)

Vertical scaling is the fastest way to get more headroom. This involves changing the instance class (e.g., moving from a db.t3.micro to a db.m5.large). I usually start here if I see CPU utilization consistently above 70%.

How to change your instance class:

1. Log into the RDS Console and select Databases.
2. Choose the instance you want to scale and click Modify.
3. Under DB instance class, select a larger instance type. I recommend the M-series for general production workloads due to balanced CPU and memory.
4. Scroll to the bottom and click Continue.
5. Crucial Step: Select Apply immediately if you are in a maintenance window, otherwise, it will wait until your next scheduled window.

Note: This will cause a brief period of unavailability as the instance reboots. If you have a Multi-AZ deployment, the downtime is significantly reduced.

Step 2: Horizontal Scaling with Read Replicas

If your application is read-heavy (e.g., a dashboard or a content site), scaling up the primary instance is wasteful. Instead, you should scale horizontally by creating Read Replicas. This offloads SELECT queries from the primary node.

Implementing Read Replicas:

1. In the RDS Console, select your primary database.
2. Click Actions → Create read replica.
3. Configure the replica’s instance size (it should generally match the primary to avoid lag).
4. Give the replica a unique identifier (e.g., prod-db-replica-1).
5. Click Create read replica.

Once created, you will receive a new endpoint. You must update your application code to route write operations to the primary endpoint and read operations to the replica endpoint. As shown in the image below, this separation is key to maintaining performance during traffic spikes.

Step 3: Optimizing Storage Performance

Sometimes the bottleneck isn’t CPU or RAM, but disk I/O. If you’re using General Purpose SSD (gp2), you might be running out of IOPS burst credits.

Moving to Provisioned IOPS (io1):

If your ReadLatency or WriteLatency in CloudWatch is spiking, switch to Provisioned IOPS. This allows you to specify exactly how many IOPS you need, regardless of storage size.

# Example: Using AWS CLI to modify storage type
aws rds modify-db-instance \
    --db-instance-identifier my-postgres-db \
    --storage-type io1 \
    --iops 5000 \
    --apply-immediately

While hardware scaling helps, you should always check if your bottleneck is actually software-related. I often find that database indexing strategies for large tables can reduce the need for expensive hardware upgrades by orders of magnitude.

Step 4: Migrating to Amazon Aurora PostgreSQL

When standard RDS isn’t enough, I move to Amazon Aurora. Aurora is a cloud-native rewrite of PostgreSQL that separates compute from storage.

Why Aurora for scaling?

• Auto-scaling Storage: No need to manually increase disk size; it grows automatically up to 128TiB.
• Faster Replicas: Aurora replicas share the same underlying storage as the primary, meaning near-zero replication lag.
• Serverless Options: If your workload is unpredictable, you can use Aurora Serverless v2 to scale compute automatically based on demand.

If you’re considering whether to stick with managed RDS or move to a more flexible architecture, you might also want to ask should i use neon serverless postgres for specific developer workflows.

Pro Tips for Scaling

• Connection Pooling: Scaling the instance doesn’t solve “Too many connections” errors. Use RDS Proxy to manage connection pooling and prevent memory exhaustion.
• Vacuuming: High-write databases suffer from bloat. Ensure your autovacuum settings are tuned, otherwise, scaling the CPU won’t fix slow sequential scans.
• Monitoring: Set up CloudWatch alarms for CPUUtilization and FreeStorageSpace so you aren’t surprised by a crash.

Troubleshooting Common Scaling Issues

What’s Next?

Scaling is a continuous process. Once you’ve implemented these changes, the next step is to implement a strict observability stack. I recommend using AWS Performance Insights to identify exactly which SQL statements are consuming the most load. This prevents the “blind scaling” trap where you keep paying for larger instances without fixing the root cause of the slowness.