The State of Snowflake Cost Management in 2026 (Webinar Recap)

• Snowflake's platform has expanded far past compute and storage, and every new service is a new place for cost to hide.
• Snowflake's Cortex AI functions are powerful, but also the easiest way to accidentally burn thousands of dollars. One customer spent $60,000 in three days on a query that was supposed to run in QA and ran in production instead.
• Visibility has to come before optimization. Teams keep finding workloads worth hundreds of thousands of dollars a year that nobody knew existed.
• The highest-ROI fixes are usually simple: running jobs less often and right-sizing warehouses, not rewriting queries.
• Scaling cost management across a growing org means giving teams their own visibility, not routing every cost question through one central team.

Snowflake used to mean compute and storage. That's no longer the full picture. Ian and Dave walked through the growing list of services customers are now running on the platform: native apps, Streamlit apps, machine learning models deployed on compute pools, a fast-growing set of AI capabilities, and even Postgres workloads following Snowflake's acquisition of Crunchy Data.

Each of these shows up as a new line item on the bill. That creates a real tracking problem: if your monitoring setup doesn't know a new service exists, you simply won't see what it costs. SELECT keeps a team of close to 30 engineers whose job is purely staying ahead of Snowflake's releases, so new cost sources get supported as soon as they ship rather than months later.

Dave added that this isn't just a technical nuisance. Leadership is increasingly making decisions about where workloads should run, and they can't do that without real cost transparency to back it up.

Snowflake's Cortex functions (now called AI SQL) let you run AI directly against data sitting inside Snowflake. Dave's example: filtering product reviews down to only the ones where the customer expressed frustration, in a single query. A few years ago, that meant humans reviewing and tagging every record by hand.

That convenience comes with a real risk. Dave shared a customer example: a query with a Cortex function baked in was meant to run in QA. It ran in production against the full dataset instead, and burned through $60,000 in tokens over three days, with nothing usable to show for it.

Ian explained why this happens so easily. AI usage is billed on tokens in and tokens out. Input tokens are roughly predictable in advance, since you can estimate the size of what you're feeding the model. Output tokens are not, because how much the model generates depends on the question itself. That asymmetry is what makes AI costs so hard to forecast before you run something.

How do you get visibility into AI spend on Snowflake?

Snowflake's account usage schema includes several views for AI. Most work like other account usage views, giving you hourly usage broken down by model. The AI SQL usage view is query-level: you can see the model used and the query text, though not the prompt itself. The most granular option is the AI observability events table. It's accessed through a table function rather than a standard view, and it can show you the prompts driving usage. It tends to be slower to query and, as Ian understands it, isn't persistent, which makes long-range analysis harder.

Do Snowflake's AI budgets and quotas actually stop runaway spend?

Mostly, with one important gap. AI budgets let you set a monthly credit limit for an account or a tagged group of objects, covering Cortex agents, Cortex search, and AI functions, and they warn you when that limit is exceeded. Per-user quotas go further and actually block usage, though enforcement takes a few minutes to kick in rather than stopping a query instantly.

The gap: a single large request can still blow past the limit before the system catches up. Ian's example was running a sentiment analysis function over a massive table of reviews in one shot. You could spend $10,000, and only the next query gets blocked. Quotas still catch the repeated or weekend-long cases, and Ian called setting them up the one thing to take away from the session. But they don't replace good practices like testing in QA on limited datasets before touching production.

How do you measure ROI on AI spend?

There's no universal formula. Start with the side you can measure precisely, which is the cost. For the value side, it depends on the use case. If AI replaces something that already existed, like a team that manually classified sentiment, compare the old cost in time and compute against the new one. If it enables something new, you're usually working with proxies: time saved, ticket or story velocity from a system like Jira, or revenue recovered. When none of those produce a clear answer, Ian's suggestion was blunt: turn it off and see who complains.

Before any optimization work happens, you need to know what things actually cost. Ian shared an example of a customer who logged into SELECT for the first time and found a workload at the top of their list costing $850,000 a year, driven largely by an AI function running inside what turned out to be a QA job. They turned it off. No deep investigation needed, because visibility alone surfaced the fix.

Dave's version of the same lesson: a customer spending $10,000 a year just to send an email out of Snowflake. One look at the real cost was enough to move that workload somewhere cheaper. He also hears "I thought I turned that off three months ago" all the time once customers see query-by-query and workload-by-workload costs for the first time.

Once you have visibility, the next question is whether an optimization is worth your time. Spending a day of engineering time to save $500 on storage is a losing trade. Spending a few hours to save $20,000 is an easy yes. Ian's advice: check that math before you start, and tackle the quick wins before rewriting any SQL.

What are the highest-ROI fixes once you know where to look?

1. Run things less often. A job that runs hourly and costs $10,000 a year drops to under $500 a year if it only needs to run daily, a 96% reduction from one configuration change. Even moving from hourly to every three hours saves roughly two-thirds of the cost.
2. Right-size your warehouse. Each size increase doubles compute and cost, so a bigger warehouse only pays off if query time actually halves too. Ian's example: dropping an ingestion warehouse from Large to Extra Small took average query time from about five seconds to about twenty, a delay nobody noticed, and saved $50,000 a year. A useful heuristic is roughly 125 partitions scanned per CPU core (a Large warehouse has 64 cores), so a query scanning only 500 partitions rarely needs more than an Extra Small.
3. Watch for the Snowflake-as-a-message-queue pattern. Dave has seen teams use Snowflake like a Kafka queue, running millions of tiny operations instead of the larger batch operations it's designed for. That keeps warehouses running nonstop and gets expensive. Match the workload to the right technology.
4. Consider horizontal scaling, not just vertical. Dave pointed out that people often choose a warehouse size and neglect cluster count. Increasing the cluster count can deliver better results than simply increasing warehouse size, depending on the workload.
5. Use AI coding agents for the harder rewrites. Ian's internal SELECT example: a dataset that was fully recreated on every run cost over $8,000 a year, and a few hours spent making the query incremental saved that spend. He added that coding agents like Coco now make this kind of rewrite possible in hours, where it used to take days.

On ingestion specifically, Ian said it typically runs around 10 to 20% of compute spend, and that share has been trending down. Snowpipe Streaming has cut ingestion costs by roughly 10x for some customers, and Iceberg adoption helps too. Dave's two easiest ingestion savings: only bring over the tables and columns you actually need, and match refresh frequency to real business need instead of defaulting to as close to real time as possible.

Are teams moving workloads to cheaper engines like DuckDB, or adopting Iceberg to save money?

At small scale, sometimes. A single engineer at a smaller company can reasonably route specific workloads to something like DuckDB. At large scale, with thousands of users who need centralized access controls, it's rare, because it's too hard to manage. Dave said he had never really thought of Iceberg as a cost-saving measure. Its draw is interoperability: you can reuse the same data from many places without spending more compute. Ian added that Iceberg can lower ingestion costs and avoids paying for storage twice, but running multiple compute engines on top of it isn't something he sees much. Dave said what he sees more often is customers moving whole workloads between platforms, such as Snowflake to Databricks or Postgres to Snowflake and back, based on fit. To him, it's about conserving compute rather than optimizing storage.

A single central data team answering every cost question doesn't scale. Dave, who has been that person, described how a small team becomes a bottleneck once every data request routes through it. The fix is empowering end users with visibility into the costs they incur, so everyone can act as a responsible corporate citizen about what they spend.

That starts with cost allocation: mapping spend to the teams responsible for it, so people's attention stays on what they can control. Different audiences need different views, too. Executives generally want high-level dashboards of cost by group over a day, week, or month. Practitioners want to see the specific things their own team is running.

Making that information easy to reach matters as much as having it. Dave suggested building relevant dashboards for each audience, or giving people access to an MCP server so they can ask Claude the right questions. Ian added that sometimes users simply need curated information in an easy-to-use UI: feed it to me, don't make me go fish for it.

A center of excellence has a real role, but a narrow one. The central team should advise users on how to improve their costs and spread that knowledge across the organization, not take responsibility for doing every optimization itself. As Ian put it, doing these things individually on behalf of the whole organization will only take you so far.