An HR tech company had its primary database on AWS's Aurora DB (MySQL). Over time, the engineering team scaled their database by upgrading the instance size, increasing IOPS, and so on. Eventually, they reached the maximum instance size available, leaving no further options for scaling. This database accounted for approximately 40% of their cloud costs. With CPU utilization nearing 100%, memory fully consumed, and IOPS consistently exhausted, the team understandably assumed that further upgrades were the only solution. This situation is a classic example of the misconception that "high utilization equals efficient utilization." The complexities of cloud environments and database management can easily mislead teams to focus on scaling rather than optimizing. The engineering team, like many others, began exploring complex solutions like switching database technologies or sharding, which would have diverted focus from growth initiatives and potentially slowed down progress.

This is where we stepped in. Leveraging our deep understanding of cloud services and databases, combined with our reverse engineering approach, we quickly identified a series of optimizations that required no re-architecture or re-engineering. We discovered that using correct data types in database tables could optimize compute resources, and implementing proper indexes would prevent table scans, thereby optimizing I/O and memory consumption. Most of these optimizations were implemented without altering the codebase.

As a result, we were able to downgrade the database instance by two sizes, while still maintaining sufficient headroom for workload spikes. This led to a 25%–30% reduction in their AWS bills. This case clearly demonstrates how high utilization does not necessarily mean efficient utilization and highlights how our approach can uncover and resolve inefficiencies that might deceive traditional solutions.