Blog Posts

Ending the Era of Abundance: Why Databases Are Ground Zero for FinOps Optimization

Written by: Ben DeBow | Founder and CEO of Fortified | Author of End of Abundance in Tech

As the author of End of Abundance in Tech: How IT Leaders Can Find Efficiencies to Drive Business Value, I’ve spent years advocating for a fundamental shift in how we approach technology. For too long, the tech industry has operated under an “abundance mindset”—unlimited resources, infinite scaling, and a disregard for the inefficiencies that pile up over time. But as cloud costs skyrocket and economic pressures mount, it’s clear we’re entering an era of efficiency. We must move beyond superficial KPIs like uptime and latency to measure the true health of our systems, including their long-term costs and sustainability. This isn’t just about cutting expenses; it’s about unlocking business value by reallocating resources to innovation rather than waste.

One area where this shift is most urgent—and most impactful—is in data and database systems. These are often the silent giants devouring budgets in cloud environments. According to a recent FinOps Foundation working group article, database management systems (DBMS) account for the largest and fastest-growing segment of cloud spending, with 98% of the 2022 DBMS market growth coming from cloud-based platforms and cloud database platform-as-a-service (PaaS) reaching over half (55%) of the market. It’s no surprise: 63% of enterprises have already migrated their databases to the cloud, and another 29% plan to do so in the next three years. Yet, this migration has introduced unpredictability, turning what was once a predictable CapEx model into an OpEx nightmare where costs can spiral due to dynamic usage and undetected inefficiencies.

In my book, I argue that the era of abundance has led to billions in annual waste from unchecked data storage and code development. Databases exemplify this perfectly. They’re not just repositories; they’re the backbone of applications, and poor architecture here ripples through every layer of your tech stack. Most database implementations feature 1-10 very large DBMS deployments that, across production and non-production environments, consume the majority (often 80%) of your budget. Within these systems, our analyses at Fortified show that the top 10 SQL statements alone can account for 53% of CPU usage and 49% of all I/O. Optimizing just these pieces of code—through better indexing strategies, adjusting call frequencies, or targeted rewrites—can yield massive savings without full overhauls.

The FinOps article highlights how cloud database costs have become the top concern for IT leaders, driven by factors like overprovisioning, inefficient queries, and vendor lock-in. For instance, suboptimal storage choices—opting for expensive SSDs when cheaper object storage like S3 would suffice for backups—can inflate bills unnecessarily. And let’s not forget backups themselves: storing them in cost-effective object storage with compression and deduplication can slash expenses by up to 80%. But to prevent recurring issues, we must shift left: change acceptance criteria for code deployments to include not just functional tests but also evaluations of cost and resource usage. If we only optimize in production, developers will continue shipping inefficient code, forcing us to clean up the mess repeatedly.

This aligns directly with the systemic approach I outline in End of Abundance in Tech. We need to forecast not just today’s capacity but the total cost of ownership over the next one to three years—much like Wall Street models your 401(k). Build a model incorporating actual or estimated transactional, data, and business growth metrics to predict sizing and costs. Involve FinOps practices early in the application lifecycle—during the design phase, not as an afterthought. As the article notes, proactive FinOps involvement helps build cost-effective infrastructure by incorporating pricing strategies upfront, balancing speed, performance, and cost. Common pitfalls like misaligned licensing (e.g., ignoring bring-your-own-license options to avoid audits) or neglecting auto-scaling decisions (vertical vs. horizontal) can be avoided with this mindset. Additionally, evaluate whether a CapEx or OpEx model suits your architecture; if an application carries significant tech debt, avoid consumption-based models that amplify inefficiencies.

So, where do you start? Databases are the ideal entry point for FinOps optimization because they consume the most resources and offer the quickest wins. Focus first on your existing high-cost systems. Here’s a practical framework, drawing from both my book, Fortified’s client experiences, and the FinOps insights:

  1. Prioritize High-Impact Systems and Code: Identify the 1-10 largest DBMS deployments driving 80% of your prod and non-prod costs. Within them, analyze and optimize the top 10 statements consuming 53% of CPU and 49% of I/O. Start with low-hanging fruit like indexing tweaks or call frequency reductions before considering rewrites.
  2. Shift Left with Cost-Aware Acceptance Criteria: Integrate resource and cost metrics into your CI/CD pipeline. Functional testing alone isn’t enough—benchmark new code for efficiency to prevent “shitty code” from reaching production and perpetuating cleanup cycles.
  3. Evaluate CapEx vs. OpEx Fit: Assess if your app’s tech debt makes a pay-as-you-go model risky. For debt-heavy systems, stick with CapEx predictability until optimizations are in place.
  4. Optimize Before Reserving: Don’t commit to reservations on day one. Delay by 90 days to tune the top 10 elements, potentially reducing initial sizing by 25% or more, then lock in another 30% savings on the optimized baseline. Right-size non-prod environments small for functional testing, scaling up only in perf/testing stages to mirror prod.
  5. Size for Workload, Not Peaks: Avoid baselining off high watermarks without investigation—90% of systems spike more during maintenance than actual app workloads. Size for the latter. Also, select CPUs with high throughput to minimize core counts; resources like CPU Benchmark show top performers like the AMD Ryzen Threadripper PRO 9995WX (PassMark 175,496) or AMD EPYC 9755 (166,328) for faster turnaround times.
  6. Forecast Long-Term: Collaborate across teams to model 1-3 year growth using transactional, data, and business metrics. Use CSP frameworks for accurate predictions and align with reservations or procurement.

By tackling databases first, you’re not just trimming fat; you’re building a foundation for enterprise-wide efficiency. In my experience at Fortified, where we specialize in database managed services, clients who adopt this approach see immediate reductions in waste and better alignment with business goals. The article echoes this: “FinOps involvement at earlier stages… can help proactively build in FinOps practices, resulting in a more cost-effective cloud infrastructure.”

The end of abundance isn’t a doom-and-gloom scenario—it’s an opportunity. IT leaders who embrace efficiency will drive real value, freeing up budgets for AI, innovation, and growth. If you’re ready to make the pivot, start with your data systems. Dive into the FinOps article for more details, and grab a copy of End of Abundance in Tech for the full roadmap. Let’s build a leaner, smarter tech future together.

Share This Article

Twitter
LinkedIn

Related Articles

Downloads

The largest blind spot in FinOps is the data estate.

Today we are publishing FinOps for Data, a Fortified research paper on one of the largest blind spots in FinOps...

Blog Posts

WISdom + Claude: Use AI to Analyze SQL Server Telemetry

Every Monday, somebody asks the DBA team a version of the same question: what got more expensive last week, and...

Blog Posts

SQL Server Activity Monitor: A Practical Guide for 2026

It is 2am, a report is timing out, and the first thing most DBAs do is right-click the instance in...

Get More Database Intelligence Insights

Subscribe to receive expert insights on SQL Server optimization, FinOps strategies, and performance intelligence.