A data platform bill that climbs every quarter is not usually a pricing problem. It is a design problem that shows up on an invoice.
I took a platform from £1.8M a year to £900K without reducing what it could do. Here is what actually moved the number, roughly in order of how much it returned for the effort spent.
1. Find out what you are actually paying for
Almost every organisation I have done this with started in the same place: nobody could attribute spend to workloads. Consolidated invoices, shared resource groups, no tagging discipline. You cannot negotiate or optimise what you cannot attribute, so the first job is unglamorous cost allocation — by workload, by team, by dataset.
This step alone usually finds something embarrassing. Mine found a development cluster that had been running continuously for fourteen months.
2. Separate storage decisions from compute decisions
These get conflated and they have completely different economics. Storage is cheap and grows predictably; compute is expensive and spikes. Most of the runaway cost in the platforms I have reviewed was compute — idle clusters, oversized warehouses, and scheduled jobs that no longer had a consumer.
Tiering cold storage is worth doing. It is rarely where the money is.
3. Kill the pipelines nobody reads
At portfolio scale there is always a tail of datasets and refreshes built for a report that somebody stopped opening two years ago. Instrument consumption, publish the list of unread outputs, and give owners a deadline to claim them. Most are never claimed.
This is a governance intervention wearing a cost-saving hat, and it improves the platform beyond the saving — less to maintain, less to explain, less to break.
4. Right-size on evidence, then commit
Once workloads are attributed and the dead weight is gone, right-size against actual utilisation rather than the sizing somebody guessed at procurement. Only then commit to reserved capacity or a discount agreement — committing early locks in your own waste at a discount, which feels like a saving and is not.
5. Make cost a design review criterion
The saving decays unless something structural changes. Put a cost question into architecture review: what will this cost at expected volume, who owns that budget, and what is the decommission trigger. It takes ten minutes and it is the difference between a one-off saving and a platform that stays affordable.
What I would not do
I would not lead with a vendor migration. Moving platforms to save money is a large, risky programme that usually costs more than the disciplined version of the five steps above, and it defers the governance work that caused the problem. Sometimes migration is right — but not as a cost-reduction tactic, and not first.
If your platform spend is climbing and you cannot say which workloads are driving it, that is a two-to-five day piece of work. Get in touch.
Leave a Reply