The Math Behind 40-60% RDS Cost Reduction With Data Archiving

Your database tables grow with every user action, every order, every event. After two or three years in production, the majority of your data is historical — rows older than 18 months that sit untouched until a compliance check or a customer support request. But you're paying full price to store, replicate, and back up every row as if it were accessed yesterday.

This post breaks down the real AWS costs behind that problem and shows exactly how archiving historical data to compressed columnar storage can cut your RDS spend by 40-60%.

A Typical Setup: What You're Actually Paying

Let's model a real-world scenario that's common among growing engineering teams:

The company: A mid-stage SaaS platform running PostgreSQL on RDS in us-east-1.

The database:

• 500 GB total across core tables (orders, events, audit logs)
• ~350 GB (70%) is older than 18 months
• Running db.r6g.large (2 vCPUs, 16 GB RAM) as primary
• 2 read replicas (same instance type) to handle reporting and analytics queries
• General Purpose SSD (gp3) storage

Here's what that costs per month at current AWS on-demand pricing:

Total monthly RDS cost: ~$916.50

And this is a modest setup. Companies running db.r6g.xlarge replicas ($380/mo each) or with 3-4 replicas are looking at $1,500-$3,000/month just in RDS costs.

Where the Money Goes (and Where It's Wasted)

Of that 500 GB, 350 GB is historical data. It's not being queried in production. It's not powering dashboards. It gets touched maybe a few times a month when someone needs to look up an old record for a support ticket or a compliance review.

But you're paying to:

• Store 350 GB of it on gp3 SSD across 3 instances (primary + 2 replicas) = 1,050 GB of redundant hot storage
• Replicate every write to it across all replicas
• Back up all of it in automated snapshots
• Index all of it, which bloats your indexes and slows down queries on recent data

The replicas exist primarily because query load increases as the table grows. More data means slower sequential scans, larger indexes, and more memory pressure. You added that second replica six months ago because reporting queries were competing with production reads. But 70% of what those replicas are scanning is data nobody actively needs.

The After: Archive and Drop a Replica

Now let's say you archive data older than 18 months to ColdPlane's compressed columnar format on S3 and delete it from your production database.

What changes:

1. Production database shrinks from 500 GB to 150 GB. Indexes shrink proportionally. Query performance improves. Vacuum operations run faster.

2. You drop one read replica. With 70% less data, your remaining replica handles the reduced query load comfortably. The reporting queries that forced you to add replica 2 now run faster on less data.

3. 350 GB compresses to ~70-100 GB in columnar format. Tables with timestamps, monetary amounts, status enums, and ID columns compress exceptionally well in columnar formats. Conservative estimates show 3-5x compression ratios. Columnar storage groups similar data types together, enabling dictionary encoding on repeated values like status codes and run-length encoding on sorted timestamps.

New monthly costs:

New total monthly cost: ~$580.75

Monthly savings: ~$335.75 (37% reduction)

That's the conservative case — one replica dropped, conservative compression, and on-demand pricing.

The Realistic Case: Why It's Often 40-60%

The scenario above is deliberately conservative. Here's what pushes savings into the 40-60% range in practice:

Larger databases compress more. A 1 TB database with 700 GB of archivable data at 4x compression stores as 175 GB on S3. At S3 Standard-IA rates, that's $2.19/month for storage that was costing $80.50/month per RDS instance on gp3.

You might drop two replicas, not one. If your replicas exist to handle analytical or reporting queries on historical data, archiving that data to a queryable format means those queries hit ColdPlane instead of your replicas. Many teams find they can drop from 3 replicas to 1.

You might downsize your instances. With 70% less data, your primary needs less memory for its working set. You might move from db.r6g.xlarge ($380/mo) down to db.r6g.large ($248/mo).

Let's model the aggressive-but-realistic scenario:

Starting point: 1 TB database, db.r6g.xlarge primary + 3 read replicas.

Savings: $1,363.81/month (69% reduction)

That's over $16,000/year.

What About the "Just Use pg_dump" Argument?

You could write a cron job that runs pg_dump, compresses the output, and ships it to S3. Many teams do exactly this. It costs nothing beyond the S3 storage.

The problem isn't the backup — it's the retrieval. When a compliance audit comes in and you need to look up a specific record from 14 months ago, here's what that looks like with a pg_dump approach:

1. Find the right backup file (which dump contains that date range?)
2. Download it from S3
3. Decompress it
4. Spin up a temporary PostgreSQL instance or restore locally
5. Wait for the restore to complete
6. Run your query
7. Tear down the instance

That's 30-60 minutes of an engineer's time for a single lookup. If your team handles 10-20 historical data requests a month — customer support escalations, audit inquiries, dispute lookups, regulatory checks — that's a full day of engineering time spent on data retrieval. At a blended rate of $75-150/hour for an engineer, that's $600-$2,400/month in hidden labor costs — which in many cases exceeds the cost of ColdPlane itself.

With ColdPlane, the same lookup is:

coldplane query run --sql "SELECT * FROM orders WHERE id = 'ord_8f3k29d'"

Results in 5-30 seconds. No restore, no temporary instance, no context switching.

The Compounding Problem

Database costs don't just grow — they compound. Every month adds more rows, which eventually triggers the next scaling event: a bigger instance, another replica, a storage upgrade. These are step-function cost increases that happen suddenly after months of gradual data growth.

A company adding 100,000 rows per month with an average row size of 2 KB grows roughly 200 MB/month. That's 2.4 GB/year — not dramatic in isolation. But across 3 replicas with indexes and bloat, you're looking at 10-15 GB/year of actual RDS storage growth. After 5 years, you've accumulated 50-75 GB of extra storage costs across your fleet, and your indexes have bloated to the point where you're considering that third replica.

Archiving at 18 months creates a natural ceiling on your production database size. Your tables stay roughly the same size year over year, which means your instance sizing, replica count, and storage costs stabilize instead of growing linearly with your data.

Running the Numbers for Your Setup

To estimate your own savings, you need four numbers:

1. Current RDS monthly spend (instances + storage + replicas). Check AWS Cost Explorer, filter by RDS.
2. Total database size. Run SELECT pg_database_size('your_db') in psql.
3. Percentage of data older than 18 months. Run a count query on your timestamp column.
4. Number of read replicas and whether any exist primarily for historical data queries.

A rough formula:

Potential savings = (archivable_storage × $0.115 × num_instances)
                  + (droppable_replicas × instance_cost)
                  - (archivable_storage ÷ compression_ratio × $0.0125)
                  - coldplane_plan_cost

Use a compression ratio of 3-5x for typical relational data. If your tables have a lot of repeated status values, nullable columns, or enum-like fields, you'll be closer to 5x.

The Bottom Line

The 40-60% claim isn't marketing. It's arithmetic:

• RDS charges $0.115/GB/month for gp3 storage, replicated across every instance
• S3 Standard-IA charges $0.0125/GB/month — roughly 9x cheaper per GB
• Columnar compression reduces the data volume by another 3-5x
• Fewer rows in production means fewer replicas needed

For a company spending $1,000-$2,000/month on RDS, archiving historical data typically saves $400-$1,200/month. The exact number depends on your replica count, instance sizes, and how much of your data is archivable.

The data isn't deleted. It's compressed, encrypted, and queryable in seconds whenever you need it for a support request, an audit, or a compliance check. You just stop paying hot-storage prices for cold data.

Note: This post uses AWS RDS pricing because it's the most common managed database provider, but the same math applies to Azure Database for PostgreSQL, Google Cloud SQL, or any managed database where you're paying per-instance compute and per-GB storage. The ratio between hot storage and object storage costs is similar across all major cloud providers.

---

Ready to see what your savings would look like? Start with ColdPlane's free tier — archive up to 5 GB with no credit card required.