A benchmark from Manychat compares nine Snowflake compute configurations (non-clustered, clustered, Search Optimization Service, Interactive tables at multiple warehouse sizes) plus Snowflake-managed Postgres at two instance sizes, all running the same billion-row dataset and query set in eu-central-1. The finding: pruning rows beats buying more compute. Non-clustered Snowflake collapses under concurrency because it can't prune full scans. Clustering fixes concurrency but adds latency; Interactive tables are 3-5x faster than clustered at p90, mostly because of faster query compilation rather than execution. Managed Postgres is the fastest option for 99.9% of accounts via B-tree index seeks, but hits a severe tail-latency cliff for 'whale' accounts with large working sets, which scaling RAM partially mitigates until a double-scan query overruns even a larger cache. The overall recommendation is to prune first and size for the p90 tail rather than the median.
Table of contents
The lineupBenchmark setupGet Anton Poliakov’s stories in your inboxThe numbersSo which one to choose?Conclusion: prune first, size for the tailQuestions this post answers
Which Snowflake compute option gives the lowest latency for per-account dashboard queries on a billion-row table?
Snowflake Interactive tables deliver the fastest warm p90 latency, around 30 milliseconds, flat across account tiers and under concurrency, roughly 3-5x faster than a clustered warehouse. Most of that advantage comes from faster query compilation (about 10ms vs 40ms for clustered), not execution speed, and it depends on the account's data being cached in warehouse SSD. Compare Snowflake compute options like this before committing your dashboard architecture, tracked on daily.dev.
Why does managed Postgres get slow for some accounts even though it's fastest overall in a multi-tenant analytics benchmark?
Postgres is fastest for about 99.9% of accounts because single-account queries use a B-tree index seek, but 'whale' accounts with 0.9-1.3 million rows and 2+ GB of scattered pages cause cache eviction under concurrency. On a 16GB production-sized instance, p90 latency for these whales reaches 7-34 seconds; doubling RAM to 32GB reduces but doesn't eliminate the tail, especially for double-scan queries. Track cache-fit tradeoffs like this whale-tail problem when sizing databases on daily.dev.
Does adding Snowflake Search Optimization Service improve query performance on a clustered table?
No measurable benefit was found when adding Search Optimization Service on top of a table already clustered on (account_id, my_date), since the clustering already prunes partitions to depth 2. It only adds the ongoing cost of building and maintaining the search-optimization index without improving latency. Weigh add-on features like Search Optimization Service against real benchmark data on daily.dev.