Predictable cloud cost from the moment the architecture is designed.
A data platform does not become expensive by accident: it becomes expensive through architecture decisions made early and revisited late. We design with the cloud bill in mind, making sure that the scale of the data does not destroy the profitability of the business.
Where the lakehouse bill grows
Four sources of spend that show up in almost every Databricks and Azure environment that grew faster than its architecture.
A cluster running with no work to do
Interactive environments left up all day, badly configured auto-scaling, and jobs running on general-purpose clusters. The bill counts machine hours, not results delivered.
Reprocessing everything to update very little
Pipelines that reread the whole table on every run when only one day of data changed. This is usually the item that dominates the compute bill on a platform that grew fast.
Files too small, reads too expensive
Thousands of tiny files, partitioning chosen at the start and never revisited, no compaction. The same data costs more to read with every passing month.
Spend nobody can attribute
With no tagging by business area, product or project, the whole bill lands on IT and the conversation becomes an across-the-board cut. Without knowing whose spend it is, no business decision is possible.
Cost is a project stage, not a report at the end.
FinOps here is not a separate service: it is three of the six stages of the Planncode method, which already address financial efficiency before, during and after delivery.
Stage 02 Architectural Design
Cloud cost optimisation, as in Azure Databricks, is planned from the outset to avoid financial surprises. Sizing, environment separation and ingestion strategy are architecture decisions, and it is cheaper to make them now than to correct them later.
Stage 04 Validation and Efficiency
Before considering a delivery finished, we validate whether it is financially sustainable and whether it meets the agreed ROI criteria. A solution that works but costs more than it returns has not passed the test.
Stage 06 Stewardship and Evolution
With a stewardship mindset, we keep monitoring and suggesting optimisations once the platform is already running. Cloud cost is not a one-off adjustment: data grows, usage changes and the architecture has to keep up.
Governance is what makes the cut safe
Cutting spend without governance is betting that nothing will break. Knowing who consumes what, and what depends on what, is what turns a cut into an informed decision.
What we put in place
The same governance foundation we apply on data projects, now read through the lens of cost: without it, nobody knows whose bill it is or what can safely be switched off. The reasoning behind that foundation is in the article on data infrastructure.
- Unity Catalog for unified lakehouse governance
- Granular access control, both for who queries and for who provisions
- Auditing and compliance with a trail of what was accessed and changed
- Data lineage, so you know what breaks before switching off a pipeline
What this looks like day to day
Chargeback by business area and by data product, a policy for who may create environments, periodic review of what is up but no longer used, and the cost conversation happening with the business team, not only with IT.
We work on the client platform. If it runs on Databricks or Azure, see the scope of our Databricks partnership and our Microsoft partnership.
The evidence we have
Analytics Platform with Azure Databricks
An analytics management platform able to handle large volumes of data while keeping costs under control.
- The solution was implemented within budget and schedule
- New data possibilities explored on a sustainable solution
Is your cloud bill growing faster than your usage?
Tell us the context of your environment and we will look at the architecture before talking about cuts.