Our AWS RDS bill for PostgreSQL was crushing us.
We were shelling out $28,000 a month for a single database instance, and honestly, it felt like we were just throwing money into a black hole. Three months later, that same bill is now $7,500. A 73% cost reduction. How’d we do it?
Turns out, the answer wasn’t more code, but better specs. For a 6-person dev team building a Next.js SaaS, that $28K/month was unsustainable. We were running a db.r5.2xlarge instance, which felt like overkill, but we were constantly hitting performance bottlenecks. So, what did we do first?
The usual stuff. We spent weeks trying to optimize individual queries, adding indexes, tweaking settings. It barely moved the needle. We even tried auto-scaling groups, but they were too reactive and still left us over-provisioned most of the time. Honestly, I was wrong; we totally underestimated the root cause.
Here’s the thing: we were trying to fix symptoms, not the disease. Our database looked busy because our schema was inefficient, forcing complex joins and unnecessary data fetches. That’s when we had our ‘aha!’ moment: Specs are cheaper than debugging. It’s way more cost-effective to design a database that runs efficiently on a smaller instance than to throw a monster server at a poorly designed one.
Become a Medium member
We realized we needed to go back to basics, focusing on schema first. Our main strategy was simple: right-size the instance and optimize the schema. We moved from that beefy db.r5.2xlarge to a much smaller db.t4g.medium on AWS RDS. This meant a complete overhaul of our PostgreSQL 15 schema.
We redesigned key tables, denormalized where it made sense, and focused on reducing table joins for our most common queries by a whopping 40%. To help with this, we even built a small internal Python tool, our ‘Schema Whisperer,’ that analyzed query patterns and suggested schema improvements. The trade-off? This took about two weeks of dedicated engineering time from our team, but it dropped critical query latency from 150ms to 80ms. So, yeah, it wasn’t a magic bullet.
The upfront engineering time was significant, and it required a deep dive into our application’s data access patterns. This approach is not for everyone, especially if you’re dealing with extremely high-traffic, bursty workloads that genuinely need massive instances, or if you don’t have anyone on your team comfortable with database schema design. But for us, a SaaS with predictable growth, it was a game-changer.
We’re now running smoothly at $7.5K/month, a 73.2% cost reduction, and our database is actually performing better. It really hammered home that over-provisioning is a silent killer for startups. We’re still figuring out the optimal scaling strategy for future growth, but this fundamental shift has saved us a ton. Anyone else dealt with similar database cost nightmares? What’s your approach to keeping cloud DB costs in check without sacrificing performance? Curious if others have hit this ‘specs vs. code’ realization too.
Top comments (0)