Hacker News Reader

Comment by lokar | Hacker News Reader

To me to key “insight” is that if you are going to spin up single VMs (or even groups) per-customer and then route queries, you need to be able to estimate the query cost first.

I know snowflake does this, they do the query optimization before sending it for execution. So it knows about how many resources will be needed (it can obviously be wrong).

View on HN

[Author] Basically yes, but we spun up pods on EKS. It was hard for the customer to estimate how much they might need and hard for us to know how much capacity to provide. Given our plans on pricing on CPUHours (or similar) the logic was kinda broken.

How does Snowflake use that information? You still need to pick the warehouse. It would be cool if there was an "elastic warehouse" where heavier queries are routed to bigger Warehouses, but that's not the case

There is an elastic option, I think . Also, even with a specific warehouse, not every query uses every node in the warehouse.

Right, there is an option to scale horizontally, if a lot of queries are queued, Snowflake can spin up another node. But that doesn't help if you query is spilling to remote storage. You need a bigger node to speed up those queries.

Snowflake has an option to add more resources, which is supposed to be vertical scaling, but it doesn't work as well as increasing the size of the warehouse

The query planner / optimizer does not run in the warehouse. One of its primary functions is to predict this stuff.

[Author] Basically what we are doing with the help of Trino: a distributed query engine which can use as many resources as the query needs dynamically.

Reply on news.ycombinator.com