Don’t be sorry.
I know they do make performance improvements and for that I am thankful.
However flux is not a beta or “an alternative” anymore. Is the current default and most supported way of querying your cloud offering. And having that abysmal difference in performance with a language that is “in its way out” (and you are very welcome to call this one out by saying that the language will get new features in the future) after a long time in beta and a nice production run.
I could understand a duality (soon to be trio) if there was performance parity and equal library support. There is none.
New Javascript libraries are quite nice, yet they only support flux. In order to use the compatibility endpoint (which surprisingly offers hands down best performance) I am forced to use an older library that does not have the features or the support of the new one. On top of that is the GET only implementation of the query endpoint and the need to annoyingly having to create dbrp mappings if influxQl needs to be used.
Flux may be nicer for another (possibly majority) of users, but it really made our interfacing with our time series data much worse. And for that I am not really thankful.
Anyhow I will be trying to get my queries modernized and switch to flux when performance is in the same ballpark.
Thanks for trying to get us there.
