The Data Huddle by Yuki is a podcast about modern data leaders at global companies. The people who make data work every day, but rarely get the spotlight. Honest conversations about their careers, wins, mistakes, and how they see the future of AI and data.
What changes when you stop advising companies on their data platform and start owning one?
In this episode, Dana Bilder-Morozova sits down with Dan Greenberg, who owns the Snowflake data platform at Verisk. They talk about what most companies still do not know about their compute cost, why AI token spend is now the harder problem, and the habit he built so he never has to learn about a problem from an invoice.
About the Guest
Dan Greenberg has been working with data for longer than most of the categories he works in have existed.
Seventeen years as a SQL Server DBA. Then deep into business intelligence with QlikView and Qlik Sense, and a Qlik Luminary. When the BI consulting market got crowded, he went back to his data roots and spent the last six to eight years focused on cloud data platforms, mostly Snowflake.
Today he owns the Snowflake data platform at Verisk, one of the largest data and analytics companies in insurance. A business where data is not a by-product of the work. It is the product.
He also describes himself, without prompting, as a Snowflake fanboy. He dates the conversion to the first time he accidentally dropped a table and someone told him about UNDROP.
Episode Highlights
From Consultant to Owner, and Why It Got “A Lot More Personal”
He spent years advising other companies before taking ownership of a platform himself. Asked what changed, he gives an answer most consultants would not say out loud.
“Working for a corporate job as opposed to consulting is different, and it’s a lot more personal, where I take cost optimisation and governance a lot more seriously than I was in the past as a consultant.”
It is a small sentence with a large implication.
Cost discipline is not primarily a skills problem. It is a time-horizon problem. A consultant leaves at the end of the engagement. An owner is still there when the bill arrives, and again the month after that.
On why he chose data in the first place, long before it was fashionable, his answer is blunt.
“Data’s always been currency. You can’t have an application without data. You can’t have information without data. You have nothing if you don’t have the data behind it.”
What Vendors Get Wrong When They Pitch Him
Now on the buying side, he sees a lot of outbound. His first complaint is about competitor comparisons, and it is more interesting than the usual grumble.
“You cannot look at product comparisons and you cannot publish one, because what was true today may not be true tomorrow.”
The problem is not that comparisons are biased. It is that they are perishable.
“I’ve seen so many product comparisons given to me by vendors where they’re talking about features, or lack of features, on a competitor that haven’t been an issue for four years or more. These videos and LinkedIn posts and articles live on forever.”
In a market where every platform ships quarterly, a comparison chart is accurate for about a season and quotable for a decade.
His second red flag is the cheapness claim.
“It’s always a bit of a red flag when they start to say how much cheaper they are than a competitor, because it’s generally not an accurate comparison.”
He walks through why the maths usually hides something. Yes, but you carry more infrastructure cost on your side. Yes, but you need a different skill set to maintain and administer it.
“I’m always wary when companies say they’re three times, seven times, eleven times – I’ve even heard fourteen times cheaper than a competitor.”
What earns credibility instead is unglamorous. Real use cases, with real client names.
“It’s hard when they’re a new company, but it’s important to be able to reference other companies and how they’re utilising the tool and what they’ve seen.”
Did Companies Actually Know What Their Compute Cost?
He has seen the inside of a lot of data organisations. Asked whether they knew what their compute was costing them, the answer is no.
The reason is subtler than a missing dashboard.
“Some things are easy to know – an extra small warehouse in Snowflake is one credit per hour. But to understand what that really means takes a deeper level of understanding than most companies have.”
The real question, in his framing, is marginal rather than absolute.
“What’s the impact of running this extra query that’s going to run for an hour on an already running warehouse? Is it going to add an hour to it? If so, okay, it cost a credit. Is it going to add 10 minutes overall? Then it’s a sixth of a credit.”
Which leads to the anti-pattern he sees most often. Teams adopt it for good reasons.
“A lot of companies go about things the wrong way and say, we’ll have a separate warehouse for human resources, we’ll have a separate one for accounting, we’ll have a separate one for finance.”
The intent is accountability. The result is idle capacity nobody is sharing.
“It ends up costing them a lot more money, because they’re spinning up an otherwise idle warehouse, whereas a different department’s warehouse could easily accommodate their query load.”
His point is that the two goals were never actually in conflict.
“You could still get the same governance and accountability and see who spent what, but you just have to think about it a little bit more.”
Sizing is equally unresolved, and he is fair about why. Even the vendor’s own guidance is empirical. Try a size, and if it is slow, try the next one up.
“Even though your query might run considerably faster on the next size up warehouse, what’s the overall cost going to be? Could that have been accommodated on a smaller warehouse that already has capacity, and just take a little bit longer to run, and ultimately be cheaper?”
Why Mature Companies Still Overspend
We asked the question we put to every guest, because we see it constantly with clients who are by any measure sophisticated. If these teams are mature, why is this still happening?
His answer is almost disappointingly ordinary, which is what makes it credible.
“There’s too much work. There’s never a shortage of work. And it’s hard to prioritise and say, I think I can save a couple of dollars if I go and analyse our warehouses for a couple of weeks and see if there’s room for consolidation.”
There is also the problem of not knowing the size of what you are not looking at.
“A lot of companies have that issue. They may not realise they have the issue, and how big of an issue it actually is.”
And when someone does look, the numbers are rarely marginal.
“A lot of companies come in and have a strategy – yeah, we’ll just use an extra small warehouse for everything. And you show them how they’re wasting thirty percent, forty percent or more on certain workloads.”
His conclusion is one every platform owner should sit with.
“Even for mature organisations that have been on Snowflake for years, there’s generally room for experts to come in and optimise.”
Optimising Compute to Pay for AI
Asked whether enterprise thinking about compute cost has actually changed in 2026, he says yes. But not in the direction most people assume.
The motive is not thrift.
“I see a lot of companies trying to optimise their compute cost, not so much as an overall saving, but to free up budget for more AI.”
He gives the arithmetic from a real account. Roughly 800 users, around 180 of them using Cortex Code in a given month, costing a few thousand dollars.
“That money’s got to come from somewhere. So saving it off of compute can free it up for additional use cases.”
This reframes the whole cost conversation.
Optimisation is no longer a defensive exercise to report savings at the end of the quarter. It is how the AI roadmap gets funded without a new budget request.
“You Shouldn’t Wait for the Snowflake Bill to Know What’s Driving It”
We asked whether he knows what drove his Snowflake bill when it arrives. He rejected the premise of the question.
“You shouldn’t wait for the Snowflake bill to know what’s driving it.”
So he built the alternative himself.
A utility monitors running queries. When one crosses a threshold – he started at 30 minutes and has since raised it to about an hour – it notifies him in near real time, with AI-generated tips attached.
“Without even going to a computer, just looking at my phone, I see – this person’s got a Cartesian join. This is never going to finish. Let me call them, have them cancel it, and tell them how to optimise this query.”
His reasoning for why that specific case is worth catching is the sharpest cost argument in the episode.
“Nothing is more expensive than that query that runs and runs and runs and times out without any results. Because you’ve gotten no results, you’ve gotten no value, and it’s got to be run again.”
And then the part that doubles the damage.
“What do people do when that happens? They run it again. So it’s costing us 2x, 3x for that query that never completes and never will complete.”
Worth naming what that is. It is not reporting.
It is intervention, at the moment the money is being spent, rather than four weeks later when it is a line item.
Where AI Cost Governance Still Falls Short
Credits and tokens are one budget for him, but he watches them separately.
The first thing he does every morning is open a report of all AI usage, broken down by individual user and service, with the ability to drill into the queries behind it.
That is not a preference. It is a workaround for two specific gaps in how AI spend controls work today.
The first is latency.
“There’s latency of seven to ten minutes before that will show up against your usage. So even if you put a dollar budget on it, someone could run a query that cost $100.”
By the time the system knows, the money is gone.
The second is concurrency.
“There’s nothing that would prevent people from firing off 10 queries that will cost $100 each, and all of them start to kick off before it sees any consumption of tokens and controls it.”
A budget that reports after the fact and does not account for parallel queries is not a limit. It is a record.
So he is building around it. A Streamlit application estimates the token cost of an AI query before it runs. Under the threshold, it executes. Over it, the request is logged and sent for management approval.
He expects the platform to close the gap eventually – “I’m sure they’re coming in time” – but he is not waiting.
Which is also his answer to the two-to-three-year question.
“I think compute is less of a problem than the token cost for AI.”
Embrace AI or Be Run Over by It
On what Snowflake customers should prepare for, he widens the question to everyone working with data.
“Whether it’s data engineers or analysts, they really need to embrace and master AI or be run over by it.”
His framing of the choice is simple enough to put to any hiring manager.
“Would you rather have a data engineer that’s very good, or one that’s 30% more effective and productive because they know how to use AI properly?”
He is pointed about the resistance he sees, and it is not coming from the people you would expect.
“There’s a lot of people who are very skilled that I know personally who don’t want to use Cortex Code. I know how to do it – well, that’s great. But you could punch in a prompt instead of writing 10 queries, and come back a few minutes later after you’ve cleared out your inbox.”
His conclusion is not softened.
“Eventually those data engineers that don’t embrace and master AI will potentially be out of jobs.”
Real Value Versus a Solution Looking for a Problem
Asked how to tell an AI project that moves the number from one that is showing off, he answers with a story rather than a framework.
A summer intern with nominal computer skills built a Streamlit application that manages their dbt releases, handles artifact uploads, and sends notifications to different teams. It is driven dynamically from a table, so new checks can be added without new code.
“There’s no way that intern could have done it without AI. The value we got from this intern was tremendous.”
His definition of hype is equally concrete.
“To me it’s when you have a solution looking for a problem.”
He then gives an example against his own enthusiasm.
Snowflake’s Document AI is, in his words, a great tool. It is also the wrong fit for his data, because the PDFs he works with are very large, very complex and inconsistent.
“It would be round peg, square hole, trying to fit a problem to the solution.”
A rare thing to hear from someone who calls himself a fanboy of the platform.
Dashboards, Excel, and What Refuses to Die
We put a previous guest’s claim to him – that dashboards will never die – expecting a fight. With seventeen years of BI behind him, he agreed instantly.
“It’s kind of like you can’t kill off Excel. As BI developers, the worst thing we could hear is, oh, I open your dashboard, I do this, and then I export to Excel.”
He knows exactly who that answer disappoints.
“I know that’s not what AI companies want to hear, but there’s still certain data presented certain ways that people want to see. I can guarantee you that the C-suite wants to see a PowerPoint with that information, and finance people want to see an Excel.”
His verdict on the whole debate is one line.
“It’s idealistic to think that BI will go away and dashboards will go away.”
Measure Twice, Cut Once
His advice to a company that has just started on Snowflake is a carpenter’s proverb. The horror stories behind it are specific.
“Come in with the knowledge you have about other database platforms and your other IT experience. But ask experts, engage a consulting company, talk to your Snowflake sales reps, make sure that what your plan is makes sense.”
The worst version he has seen was a company that created seventeen thousand unique roles. One per person, per function. Two people on the same team doing the same job could not touch each other’s tables.
“That was a nightmare and took a lot of time to fix.”
His most practical tip is about role-based access control, and it will save someone reading this a support ticket.
“Instead of saying this role has access to this table, this table and this table, you grant access to all tables and all future tables in the schema.”
The failure it prevents is quiet and common.
“If someone creates a new table, or drops and recreates a table – which is very common – it will lose its grants. And that person all of a sudden doesn’t have access to that table anymore. I’ve seen that far too many times.”
Underneath all of it is a question he wants new teams to keep asking. You know how this worked on your old platform. Is that the best way to do it in a modern cloud environment?
The Bottom Line
The through-line of this episode is timing.
Dan Greenberg’s cost discipline is not built on better reports. It is built on moving the moment of detection earlier. A phone alert while the runaway query is still running. A daily AI usage report instead of a monthly invoice. A token estimate before the query executes, rather than a budget warning seven to ten minutes after it finished.
Every one of those is the same idea applied at a different layer. All of them exist because the platform’s own controls report faster than they prevent.
The rest is unglamorous and widely applicable. A warehouse per department feels like governance and often is not. Mature teams overspend because nobody has two weeks spare to go looking, not because they lack the skill. Compute optimisation is now how AI gets funded, which makes it a growth lever rather than a cost exercise.
And the people most at risk from AI are not the least skilled ones.
They are the skilled ones who have decided they do not need it.
The Data Huddle by Yuki – honest conversations with the data leaders building the future.
