Data Lake Metrics Your CFO Actually Cares About

Key Takeaways

• Most data lake reports are written for the people who built the lake. Terabytes, pipelines and uptime tell a CFO almost nothing about whether the money was well spent.
• Cost per workload beats total platform spend. A rising bill is fine if it tracks to more useful work. You can only tell with costs tied to teams and use cases.
• The lake earns its keep through what you turn off. Legacy licenses, servers and duplicate extracts retired is the most concrete number you have. Track it on purpose.
• Time to data and active consumers show value. How fast a request becomes a dataset someone uses, and how many people and agents use it, are the closest things to a revenue line a data platform has.
• AI readiness is now a finance metric. The share of planned AI use cases that run on governed data tells the CFO how much of the AI budget is at risk before it is spent.

Picture the first finance review after a data lake goes live. The company spent a year building it. The data team is proud of it, and they should be. The slide says "38 sources ingested, 126 tables, 99.9% uptime." The CFO nods and asks the only question they care about: what did we get for the money?

Nobody has a clean answer. The lake didn't fail. Nobody decided up front what "worth it" would look like in finance terms.

This matters more than it used to. The data lake used to be a reporting project. Now it is the foundation for every AI initiative on the roadmap, and the budgets are bigger. Fivetran's survey with Vanson Bourne found that organizations lose on average 6% of global annual revenue to AI models built on inaccurate or low-quality data. (Fivetran sells data movement, so read that with the sponsor in mind. The direction matches what everyone else is saying.) Gartner goes further and predicts that through 2026, organizations will abandon 60% of AI projects unsupported by AI-ready data.

So the lake is now the thing standing between the AI budget and a write-off. That makes it a finance conversation whether the data team likes it or not.

Here's the test I'd apply: a data lake is a cost center until you can show what it replaced and what it made possible. The metrics below are the ones that show both.

Storage Is Cheap, and That Is the Problem

Storage costs almost nothing per terabyte. That's the pitch for a lake, and it's true. It is also why lakes get expensive.

When storing data is nearly free, nobody deletes anything. Every team lands its own copy. Compute jobs run on schedules nobody remembers setting. The bill grows a few percent a month, and because no single line looks big, nobody owns it. The Flexera 2026 State of the Cloud Report puts estimated wasted cloud spend on IaaS and PaaS at 29%, and a data lake is one of the easiest places for that waste to hide.

Terabytes stored is the metric data teams report most often. It is close to useless for a CFO. A lake that doubled in size could be twice as valuable or twice as wasteful, and the number can't tell you which.

Report cost by owner, not by bucket

Tag every storage zone and compute workspace to a team and a use case from the first day. Then the monthly report says "the pricing team's models cost X, the finance close dashboards cost Y," not "S3 cost Z." The CFO can argue with a line that has an owner. They can only shrug at one that doesn't.

Cost Per Workload Matters More Than Total Platform Spend

I'll state this flat: total platform spend is the wrong headline number for a data lake.

Total spend should go up. If the lake is working, more teams use it, more reports run on it, and more AI workloads read from it. A finance team that sees only the total will try to hold it flat, and the fastest way to hold it flat is to stop new teams from onboarding. That defeats the point of building the thing.

The number that matters is cost per workload. What does it cost to refresh the board reporting pack each month? To keep the forecasting model current? To serve the documents a support agent searches? When that unit cost falls while total spend rises, you are buying more output for less per unit. That is the story a CFO wants to hear, and you can only tell it with attribution in place.

Pick one unit per workload

Don't build a perfect cost model. Pick one plain unit for each major workload: cost per dashboard refresh, cost per model retrain, cost per thousand documents indexed. Report the trend monthly. Precision matters less than consistency. A rough unit tracked for a year beats a perfect one invented for a single review.

The Lake Pays for Itself Through What You Turn Off

This is the metric most teams forget to track, and it's the one the CFO believes most.

A data lake usually replaces something. An aging on-premises warehouse. A reporting server under someone's desk. Licenses for tools that only existed to move data between systems. A pile of spreadsheet extracts that analysts rebuild every Monday. Every one of those has a cost, and every one should go away once the lake is live.

But "should go away" is doing a lot of work in that sentence. Legacy systems linger. Someone keeps the old warehouse running "just in case." A team keeps pulling its own extract because they don't trust the new tables yet. Six months later the company is paying for the lake and everything it was supposed to replace.

Legacy spend retired is the cleanest number you have. It is real money, it shows up in the general ledger, and finance doesn't have to take anyone's word for it.

Keep a decommission ledger

Before migration starts, list every system, license and contract the lake is meant to replace, with its annual cost and a target shutoff date. Review the list monthly. When something gets turned off, mark it and record the saving. When something misses its date, find out why. Usually the reason is trust, and trust is a data quality problem you can fix.

Time to Data Is the Cost Finance Pays Without Seeing It

Ask a business team how long it takes to get a new dataset today. The answer is usually measured in weeks. A ticket goes in, an engineer scopes it, a pipeline gets built, someone checks the numbers, and by then the question that prompted the request has been answered some other way, usually in a spreadsheet.

That delay is a cost. It doesn't show up on any invoice, which is why it rarely makes the report. But it is the cost that matters most to the business, because every week a pricing analyst waits for data is a week of decisions made on gut feel. The Fivetran survey above also found that data scientists spend 67% of their time preparing data. That's expensive people doing plumbing.

A well-built lake should shrink time to data. Curated data products, a catalog people can search and access policies set up front mean a new request usually becomes a new view on existing data instead of a whole new project.

Measure request to first use

Start the clock when someone asks for data. Stop it when they use the result, not when the pipeline ships. Report the median every month. If it isn't falling, the lake is growing without getting more useful. That's a hard number for a data team to look at, which is exactly why it belongs in front of finance.

Count Consumers Before You Count Terabytes

Queries executed is another number that looks good on a slide and says very little. One badly written dashboard can run ten thousand queries a day. A single analyst making a call that saves a quarter can run five.

The better question is who is using each data product. How many people, how many reports, how many agents. A curated customer table with forty active consumers is an asset. A curated table with zero consumers in ninety days is storage and maintenance cost with nothing on the other side.

This is also where a lake's value compounds. The first consumer of a clean dataset pays for building it. Every consumer after that gets it nearly free. A CFO understands that shape immediately. It's the same reason shared services beat every department building its own.

Retire data products nobody uses

Review consumer counts quarterly. Anything with no active consumers gets a warning and then gets archived. It feels wasteful to delete work. It is more wasteful to keep paying to refresh, test and govern a table nobody reads.

AI Readiness Is a Finance Metric Now

Two years ago I would have left this one off a CFO report. Not anymore.

Most companies have a list of AI use cases they want to fund: an agent that answers questions from contract files, a model that forecasts demand, a tool that drafts the monthly close commentary. Every one of those depends on data that is clean, governed and reachable. If the data isn't ready, the project stalls, and the money spent on it is gone.

So I'd add one line to the report: the share of planned AI use cases whose data already lives in the lake, governed and documented. If the AI roadmap has ten items and the lake covers three, the CFO knows that seven projects carry data risk before a single dollar goes to a model. That's a much better conversation to have in planning than in a post-mortem.

Unstructured data matters here more than most data teams expect. Contracts, emails, call transcripts and PDFs are what agents need most, and they are often the last thing to land in the lake. PressW builds document zones into the lake for exactly this reason. On one engagement, we indexed 100GB+ of training videos and blog content into a single searchable library and cut the time real estate agents spend finding training material by an estimated 80%+.

Map every AI use case to its data

Make a simple two-column list: the AI use case and the datasets it needs. Mark each dataset as in the lake, in progress or missing. The percentage that's ready is your coverage number. The missing ones are your data roadmap, in the order the business cares about.

Five Numbers on One Page

Here's the framework. Five numbers, one page, reviewed monthly by someone from the data team and someone from finance in the same room.

None of these numbers is hard to compute once the lake is built with them in mind. All of them are hard to reconstruct after the fact. That's the real point: decide what you'll report before the first file lands.

Give each number an owner

Every metric needs one name next to it. The data lead owns cost per workload and time to data. Finance owns the decommission ledger. Business leads own their consumer counts. Whoever runs the AI roadmap owns coverage. A metric without an owner gets reported once and then quietly disappears.

The Lake Should Answer to the P&L

I'm bullish on data lakes, and more so now that AI depends on them. The companies that get their data into one governed place will move faster on everything that comes next.

But I don't think anyone has fully figured out how to value a data platform. The five numbers above are a start. They miss things. They don't capture the decision that was better because the data was there, or the AI project that worked because the documents were indexed. I haven't seen a clean way to measure those yet, and I'm wary of anyone who claims to have one.

What I'm sure of is that a lake reported in terabytes and uptime will eventually get cut by someone who can't see what it does. A lake reported in cost per workload, retired spend and AI coverage gets funded.

If you're planning a build, or you already have a lake and can't answer the CFO's question, start with the decommission ledger. It's the fastest number to get and the one finance trusts most. We design those metrics into every Data Lake Build Out from day one, and if you want to compare notes on what you're seeing, Book a Discovery Call.

FAQ