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).

▲

roboben 30 minutes ago | parent | next [-]

[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.

▲

gonzalohm 2 hours ago | parent | prev [-]

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

▲

roboben 29 minutes ago | parent | next [-]

[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.

▲

lokar 44 minutes ago | parent | prev [-]

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

	▲	gonzalohm 32 minutes ago \| parent [-]
		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