4 min read
The client is a leading US-based SaaS company in the productivity and collaboration sector, headquartered in Texas. Their product runs on Azure, which is where this story takes place.
When they came to us, their Azure environment was running at around $20,000 a month. They'd already done the obvious work. Reservations were in place, someone internally had taken a pass at FinOps, and the easy wins were gone. Or so they thought.
The first thing I do on any environment is look at where the money actually goes, service by service. Within the first hour, one number stood out: Backups were costing 15% of the entire account. Nobody on their side had flagged it. It wasn't on the radar.
That's a lot of money to be spending on something most engineering teams set up once and never look at again.
When you provision Azure SQL, you get two backup mechanisms running by default, and they do very different things.
A daily backup is exactly what it sounds like. Once a day, the system takes a snapshot of your database. If something goes wrong, you can restore to yesterday's state, or the day before that, depending on how many you keep.
Point in Time Restore (PITR) is a different beast. It continuously logs every transaction so you can roll the database back to any specific second within the retention window. Lost a row at 14:32:07 yesterday because of a bad deploy? PITR lets you restore to 14:32:06. It's powerful, and for most production workloads it's genuinely useful.
The catch is that all of those transaction logs get stored, and you pay for that storage. The longer your PITR retention window, the more logs are sitting there, and the bill grows accordingly.
This client had their PITR retention set to 35 days. Not the default — someone had explicitly raised it years ago, and it had been quietly compounding ever since. By the time we looked at it, nobody on the current team even knew why that number had been chosen.
Industry practice for PITR is 7 days. That's enough to cover the realistic window where you'd notice data corruption, a bad deploy, or an accidental delete and need a precise rollback. Beyond 7 days, you're almost always reaching for daily backups or longer-term backup vaults instead, which are far cheaper for that purpose.
Going from 35 days to 7 days cut 80% off the backup line item. The change itself? Five minutes of clicking in the Azure portal. No code change, no deployment, no risk to the application.
This is the part of FinOps the tooling vendors don't talk about. Reservations and rightsizing are the headline acts because they're easy to automate and easy to sell. They're also the first thing anyone with a FinOps mandate will do, which is exactly what had happened here.
But waste hides in the architecture, and sometimes in a setting someone changed years ago and forgot about. PITR retention is a dropdown in a provisioning script. Nobody reviews it. Generic FinOps platforms don't flag it because they don't understand the difference between transaction log storage and snapshot storage, or what a sensible retention window looks like for a SaaS product.
You only catch this if you've actually built and run these systems. That's where Koritsu sits. We go past the dashboard layer and into the engineering decisions that quietly shape your bill.
A five-minute change. 80% off backups. 12% off the total bill. On an environment that was already considered "optimised".