The $42,000 Waste Nobody Noticed: Why Snowflake Query Optimization Starts With Seeing

A data team we work with had a good handle on their warehouse bill. They knew their biggest pipelines, their busiest dashboards and roughly what each team spent. Nothing looked out of place.

As the company kicked off a cost reduction and efficiency effort, the data team took a closer look at their queries, and what they found took them by surprise. One user stood out: $42,000 a year spent on queries that failed. Not slow queries or expensive reports, but queries that ran, used compute, returned nothing and got billed anyway. Week after week, for months, without a single person noticing.

Nobody was careless. The waste was simply invisible. This is usually how it happens: an automated job sends the same query on a schedule. Each time, the query runs for a while, hits an error and stops. The error lands in a log nobody reads, so the job simply tries again next time. Meanwhile, the warehouse charges for every minute a query runs, whether it succeeds or not. On the monthly bill, all those failed attempts blend into one total with the work that did succeed.

That is the uncomfortable truth about most data warehouses: the biggest problems are rarely the ones people complain about. They are the ones nobody can see.

Why failed queries hide so well

A warehouse bill tells you how much you spent. It doesn’t tell you how much of that spend produced nothing.

When a query fails, the work it did before failing still counts. If it ran for 30 minutes and then hit an error, you pay for 30 minutes. If a scheduled job fails every night, you pay every night. On the invoice, those failures look exactly like successful work.

The people closest to the problem rarely see the full picture either. An engineer sees an error message once and moves on. A scheduler quietly tries again tomorrow. A dashboard user assumes the system is slow today. Each person sees one small moment. Nobody sees the pattern, and nobody sees the total.

The dashboard that almost never loaded

Here is another pattern we found in a customer’s data, this time in a single dashboard.

Over one week, the query behind that dashboard ran 239 times. 222 of those runs failed, about 93%. Some ran for a full hour before the system cut them off. Most were stopped by the person waiting, who then tried again.

Think about what that means for the people involved. Several colleagues opened the same report, watched it spin and gave up. Some came back and tried again. From their side, it was a frustrating report that “never works.” From the bill’s side, it was close to $250 a week, more than $12,000 a year, spent on a report that almost nobody actually got to see.

This is why cost and performance can’t be treated as separate conversations. The same query was wasting money and wasting people’s time. Fixing one fixes the other.

Failures are only the start

Failed queries are the easiest kind of hidden waste to explain, but they are not the only kind. A few others show up again and again:

• Retries. A query fails and the system quietly runs it again, sometimes several times, before it works. The result arrives in the end, so nobody notices it cost three times as much.
• Running out of memory. When a query needs more working memory than it has, it starts moving data back and forth to slower storage. In technical terms this is called spillage. In plain terms, the query gets much slower and much more expensive.
• Blocking. Some queries hold on to data while they run, and everything else that needs that data has to wait. One slow query can make a whole queue of other work late.

None of these show up on an invoice as a line item, and most never trigger an alert. They just make the warehouse a little slower and a little more expensive, every day.

Why gut feel picks the wrong queries

When teams do set time aside to optimize, they usually start with the query that annoyed them most recently. The report the CFO complained about. The job that broke on Monday.

That feels productive, but it is a poor way to choose. The loudest problem is rarely the biggest one. Neither story above was on anyone’s radar. They were found by looking at the numbers, not by listening to complaints.

A better starting point is simple: how much does a query cost each time it runs, and how often does it run? A query that costs a few dollars and runs hundreds of times a day matters far more than a slow report opened once a month. Fix it once, and the savings repeat every day after.

Ranking work this way changes the conversation inside the company. Instead of “we’re looking into costs,” the data team can say exactly which queries they are fixing, why those came first and what each one is worth.

A problem found is not a problem fixed

Even when a team finds the right problem, it often stays unfixed. Someone shares it in a meeting, everyone agrees it matters, and a month later the same query is still running the same way.

The reason is usually ownership. Query performance sits between teams: the analysts who wrote the query, the engineers who run the pipelines, the platform team that manages the warehouse. When a problem belongs to everyone, it belongs to no one.

Accountability doesn’t need to be heavy. It needs three simple things:

1. A name. Every problem worth fixing has one person or team responsible for it.
2. A status. Everyone can see whether it is waiting, being worked on, done or deliberately left alone.
3. Context. A short note on what was found and what was decided, so nobody has to rediscover it six months later.

With those in place, optimization stops being a one-time cleanup project and becomes a steady habit: see the problem, decide what matters most, give it to someone and follow it through.

From knowing to fixing

Once a team knows where to focus, one question remains: what exactly should change? Why does this query fail? Why does it run out of memory? What would make it cheaper without changing its results?

That answer used to mean hours of digging through query plans and logs, usually by the one engineer who knew the system best. Today it doesn’t have to. An assistant that understands your warehouse can look at the query, explain what is going wrong in plain language and suggest the fix. The engineer reviews it and decides, rather than starting from a blank page.

This is where the habit pays off. Seeing the problem tells you where to look. Prioritizing tells you what to do first. Getting to the fix quickly is what turns a finding into savings.

How Seemore helps

Both customer stories came from Seemore’s Query optimization page, built around exactly this habit.

It brings every recurring query into one view and ranks them by what they cost each time they run, so the first fix is the one worth the most. Next to cost, it surfaces the problems teams usually don’t see: failed queries, retries, memory spillage and blocking. Each query can be assigned to a person or team, given a status and annotated with a comment, so what gets found gets fixed.

When it’s time to fix a query, teams use the Seemore Assistant, or connect their own AI tools through the Seemore MCP, to understand what is wrong and how to change it. Customers working this way have solved some of the most important issues in their warehouse, not just the ones that were easiest to spot.

“Seemore assistant solved a major problem for us, that saved us 6% of our Snowflake spend. It helped me understand all the bottlenecks in a very big query that kept getting longer month by month. We implemented the changes, and since then it saved us a lot of money.”

Zach Beniash, Senior Director of Data, At-Bay

Read the full story: How At-Bay reduced manual Snowflake management with automated cost optimization and end-to-end lineage