Readyset Weekly: Issue 44
Reducing Database Storage Costs Without Hurting Performance
Storage growth is predictable, but storage bills aren't. In write-heavy systems especially, expanding datasets quietly turns storage into a persistent cost center. Here are practical ways to reduce storage costs without compromising performance or operability:
- Enable compression where it pays off: Postgres and MySQL support table-level and page-level compression, but it delivers the most benefit on cold or read-heavy data. Compressing hot OLTP tables can increase CPU overhead and write latency, so use it selectively.
- Separate hot and cold data intentionally: Not all data needs SSD-tier storage. Use time-based partitioning and move older partitions to lower-cost storage tiers to reduce spend while preserving query access.
- Archive before you delete: Compliance or audit requirements often prevent hard deletes. Move older records to an archive schema, separate database, or object storage to keep the primary system lean while retaining historical access.
- Reclaim wasted space aggressively: Deletes and updates create bloat, especially in MVCC systems like Postgres. Regular
VACUUM(and periodicVACUUM FULLorREINDEXwhen needed), orOPTIMIZE TABLEin MySQL, ensures reclaimed space is actually returned to the filesystem and not just reused internally. - Eliminate redundant copies of the same data: Replicas, backups, analytics pipelines, and cache layers often multiply storage consumption. Before adding capacity, audit how many full or partial copies of the same dataset exist across systems.
The Multiplier Effect: Why Bloat Costs Twice
The ROI of database optimization is doubled when you factor in backups. For a 10TB system, reclaiming 20% of wasted space through aggressive vacuuming doesn't just save $160/month on primary storage, it eliminates the cost of backing up 2TB of "dead" data every single day.
Based on current AWS EBS and AWS Backup rates, shifting cold data to archival tiers and eliminating bloat can save over $12,400 annually for a 10TB environment. This proves that a lean database is the most effective way to stop "storage creep" in its tracks.
| Data Scale | Monthly Primary Savings | Monthly Backup Savings | Total Annual Savings |
|---|---|---|---|
| 100 GB | $1.60 | $1.00 | ~$31.20 |
| 1 TB | $16.00 | $10.00 | ~$312.00 |
| 10 TB | $640.00 | $400.00 | ~$12,480.00* |
*Calculation based on 20% space recovery (Primary $0.08/GB | Backup $0.05/GB) and moving 50% of cold data to archive tiers ($0.0125/GB).
Storage costs rarely spike overnight; they compound quietly. Compression and archiving help, but the largest gains usually come from keeping the primary database lean and eliminating unnecessary duplication. At scale, efficiency beats expansion.
🔍 What We're Watching in the Database Ecosystem
Agentic Coding and Software Quality
In this post, Luca Palmieri makes the case that autonomous AI coding workflows can improve software quality if they are coupled with strong testing and verification discipline, not just used for throughput. In high-stakes systems like databases and infrastructure, this shifts effort toward verification and tooling, raising the overall reliability bar as these tools become more prevalent.
Antithesis highlights how we use deterministic simulation to test Readyset's behavior under extreme conditions. For anyone building database infrastructure, it's a clear example of the level of rigor required when correctness and consistency are non-negotiable.
In Case You Missed It
New on our blog: /brutal-review and the new 80/20 rule
"Good job" doesn't ship reliable systems. In this post, Readyset software engineer Michael Zink breaks down our /brutal-review workflow, a four-perspective, multi-agent Claude Code review process, and introduces the 80/20 token rule: most tokens should go toward adversarial review, testing, and hardening, not just generating more code.
Get Readyset Weekly in your inbox
One email a week — what shipped, what we learned, and what is worth reading.