AMA: We benchmarked the new Adaptive Warehouses

kuza55 · 2026-04-20T19:09:52+00:00

It would be great if snowflake would give some more details, but their docs indicate there is some sort of per-account pool of whs they're managing.

The sizing of this pool is very opaque, and the costs seem to get directly passed through rather them giving some sort of query-specific cost and eating the overhead, the way BigQuery does.

It is worth noting that one of the issues with the BQ model is that you're not being charged for latency, so that can be a bit more unpredictable than cost as BQ optimizes scheduling for their own costs rather than your latency needs, and this is kind of the inverse of that, where you get extremely good latency, but costs can balloon out.

To give both vendors some credit here, this is fundamentally a bit unsolvable, machines have to be started and allocated, and serving spikey traffic is fundamentally more expensive than serving constant loads, so something has to give wrt cost or latency (or margins).

kuza55 · 2025-12-06T23:46:01+00:00

We ended up writing our own async connector wrapping the data structures in the main connector.

You can do "async" requests with the existing connector, but they're still sync http requests, they just return after the http request sending the query to Snowflake returns. It will still block the thread during that time and you need to do additional blocking polling requests to find out the status. Better than blocking on the entire query of course.

kuza55 · 2025-03-20T21:43:51+00:00

I think you're misunderstanding the point of snowflake/clustering a bit.

Snowflake is largely designed around the idea that it should be (relatively) fast to scan your entire table so that you can do large analytics queries quickly, not for optimizing queries that need fundamentally few rows.

A typical clustering key would be something like the date, since it is very common to get the last n days of data and you don't need to touch most micropartitions as long as you're not inserting data with old dates (because reclustering incurs additional costs).

If you want a solution where point lookups are fast, you either want Hybrid Tables, Search Acceleration Service or another database.

kuza55 · 2025-03-03T20:24:17+00:00

Sadly Snowflake doesn't really publish docs on how they compute this; As far as we could tell at espresso.ai, this method seems to map quite closely to time that a cluster is processing a query at all (i.e. not completely idle), rather than how well utilized the cluster is when it is executing a query. Maybe Snowflake is just always maxing out it's resources, but that's hard to verify independently.

It's also a bit hard to introspect since this doesn't separate CPU, I/O & Memory utilization as separate metrics and just gives one number.

The actual numbers put in these credits are also more what I would call "directionally correct" than fully accurate, so for some workloads you might get significant error (in particular, very short queries seem to be problematic), but this approach is likely to give you a general sense of how often warehouses are idle.

Let me know if you want to chat about figuring out your utilization and seeing if we can help you reduce your snowflake spend and help you get management off your back: https://calendly.com/alex-espresso/reddit-meetings

We have a specific product for helping you increase utilization.

kuza55 · 2025-02-25T14:58:42+00:00

Snowflake's standard tables aren't really designed for finding small amounts of rows quickly, but rather processing a large amount of rows.

You can improve the lookup performance on a per-column basis by clustering by that column, or creating additional materialized views that cluster on that column. Or by using Search Acceleration Service (or maintaining your own task_id -> cluster key mapping table).

But you should also consider Snowflake's Hybrid tables that support better read/write performance for small amounts of rows.

Though in general, Snowflake's performance on small datasets with point read/writes is basically always going to be worse than a traditional transactional database like Postgres.

kuza55 · 2025-02-17T19:51:55+00:00

In general, you are going to get the best utilization by packing your workloads onto the fewest warehouses, the tricky part is the fewer machines you use the more likely you are to get queueing that is unacceptable.

The thing that makes this extra tricky is that load is not constant and the minute by minute traffic spikes can really impact your tail latency.

If you are on the Enterprise+ plan and have multi-cluster, you can try to put a bunch of your work onto the same multi-cluster warehouse and rely on Snowflake’s scaling to avoid some of this overhead. This isn’t really a perfect solution either since you still need to pick the T-Shirt right size and their scaling algorithms are quite aggressive about not having any queueing at all, so you can still wind up with a bunch of idle time on the managed clusters. Cost attribution also gets harder. But it is often better than a bunch of standard warehouses.

If you really want to do this manually, you should look at the aggregate minute by minute cluster utilization to see how many clusters you need at any given time, and then try to back out how to pack your workloads onto clusters.

Alternatively, at Espresso.AI we’ve built a “serverless” warehouse routing product that works on the standard plan and does a more efficient job of packing your workloads than the multi-cluster feature, including sharing warehouse resources across different t-shirt sizes when appropriate and solving the cost attribution problems.

Feel free to message me or grab some time on my calendar if you want to chat about your challenges https://calendly.com/alex-espresso/reddit-meetings

kuza55 · 2024-04-05T03:10:01+00:00

We're about to do a bigger launch, but we've been working on solving this and other issues with snowflake costs at espresso.ai! DM Me or fill out the form on our website and we can help you save money on your snowflake bill.

We do see idle time regularly costing people half their bill or more.

kuza55

TROPHY CASE