I was just watching this video yesterday: https://www.youtube.com/watch?v=Xqy5xZ2NIco Seems they are quite aggressive and will be able to keep up with the american tech giants!

I'd say more than hashing problem is a pruning problem. Let's remember that in Snowflake, a good indicator of clustering health, is the cluster depth (amount of overlapping micro-partitions). But as long as your Business Keys don't have defined ranges (min-max) that can lead to an efficient clustering, your cluster health will be as poor as that of a cluster using Hash Keys. Therefore, the more interesting question would be, in my opinion, how to achieve a healthy clustering, in order to ensure effective pruning now AND in the long term? Let's also not forget that the cluster of tables in Snowflake will degrade across time, since new information will create new clusters, which might not have the same quality as if you would cluster the table from scratch. It is possible though, to re-cluster tables in Snowflake to improve the underlying micro-partitions, but can be very demanding and expensive. I quote from Snowflake's documentation: 'In general, Snowflake produces well-clustered data in tables; however, over time, particularly as DML occurs on very large tables (...), the data in some table rows might no longer cluster optimally on desired dimensions.' So at the end, it’s not just about whether you use a business key or a hash key, but also how frequently the table experiences changes over time. In my opinion, I'd say a good option could be to explicitly define a cluster key on Hkey + LDTS, which can lead to a more effective pruning, since it reduces the likelihood of overlapping micro-partitions compared to partitioning only on Hkey.