[ashleyn]

There's no free lunch. Cloud services trade performance woes for budget surprises. This may be preferable in some cases but the tradeoff should be recognised.

[danielvaughn]

There's plenty of space in the middle though, no? Bank accounts cut you off if you hit a zero balance, or they can execute your transactions and charge you a fee. Why can't these services implement throttling or even halting if the charges hit a certain ceiling?

[mr_toad]

In some cases the query might have finished before the data hits the billing system.

[thrashh]

That’s not an argument.

As long as query #2 doesn’t run, that’s better then nothing.

[winrid]

So you want to add an overhead for each query to check an internal LRU cache that then checks the billing system? Just the overhead of hashing the query into some cacheable identifier will hurt performance.

[nrmitchi]

Disagree; cloud services trade reduced operation work for higher prices. There is nothing inherent to "cloud services" that requires budget surprises.

[hodgesrm]

> Cloud services trade performance woes for budget surprises.

I'm not sure why you think this is a trade-off. In general cloud services automate operations. Whether they are faster is unrelated. Many are not--services that use object storage for backing storage can be orders of magnitude slower than equivalent software using nVME SSD.

[richardw]

Our internal monitoring alerts for performance anomalies. Quite possible to scale and warn you.

[oceanplexian]

> This may be preferable in some cases but the tradeoff should be recognised.

It's not a "tradeoff", it's a product feature.