Not sure if you’ll get a specific reply. Things can change.
Most recent info I’ve found is this post. And it mentions a clear path to migrate will be supported for both 1.x and 2.x
@FixTestRepeat Sorry, forgot thanking you… thanks for your reply! The 21 sep blog is what I meant, too. Yes, there will be upgrade paths… but indeed I’ll take an educated guess that a new v1-SQL-based setup will be easier.
1 Like
If you’re just starting out now, using 1.8 with InfluxQL is probably your best bet. V3 will support the v1 write and query APIs, with the exception of Continuous Queries, and SELECT INTO syntax. We’ll be building data migration tools for 1.8 and 2.7 to 3.0. You can also use 2.7, with InfluxQL enabled and that will work until migrating later to 3.0.
For me that’s a good news, since I used the InfluxDB 2 compatility mode to still use InfluxQL, in particular because Grafana supported it much better as an interactive editor, and modifying the queries thus generated was much simpler (I never took the time to learn InfluxQL, it wasn’t necessary, it was quite obvious with a few examples), whereas Flux required a much more advanced apprenticeship.
So I’m delighted I that wouldn’t need to do a lot of changes to support InfluxDB 3 in my monitoring setups (I’m talking about hundreds of servers at work, it’s not just a personal setup).
Hello,
I’d like to join the discussion.
I use the Flux language to create dashboards on Grafana. Sometimes in professional environments.
I’m using powerful Flux functions that I’d hate to see disappear or become unusable.
Flux also seems easier to use than QL.
I’ve compared the refresh speed of a Flux and QL query, and Flux seems faster.
Here’s an example of a query I use. And even if the equivalent exists or will exist in QL, I don’t know how easy it will be to adapt.
import "date"
hcsh1 = from(bucket: "GIN")
|> range(start: v.timeRangeStart, stop: v.timeRangeStop)
|> filter(fn: (r) => r["_measurement"] == "Calcul")
|> filter(fn: (r) => r["_field"] == "${Charge}")
|> aggregateWindow(every: 1m, fn: sum, createEmpty: false, offset: -1h)
|> hourSelection(start: 7, stop: 10)
|> filter(fn: (r) => date.weekDay(t: r._time) == 0 or date.weekDay(t: r._time) == 6)
|> filter(fn: (r) => date.month(t: r._time) <= 3 or date.month(t: r._time) >= 11)
hcsh2 = from(bucket: "GIN")
|> range(start: v.timeRangeStart, stop: v.timeRangeStop)
|> filter(fn: (r) => r["_measurement"] == "Calcul")
|> filter(fn: (r) => r["_field"] == "${Charge}")
|> aggregateWindow(every: 1m, fn: sum, createEmpty: false, offset: -1h)
|> hourSelection(start: 16, stop: 18)
|> filter(fn: (r) => date.weekDay(t: r._time) >= 1 and date.weekDay(t: r._time) <= 5)
|> filter(fn: (r) => date.month(t: r._time) <= 3 or date.month(t: r._time) >= 11)
hcsh = union(tables: [hcsh1, hcsh2])
hcsh
|> sum()
|> map(fn: (r) => ({r with _time: r["_time"], _value: (r._value * 0.2)}))
Also, it’s not just in Grafana that I use Flux.
I also use it in Node-Red for queries, transformations and database feeds.
This big change doesn’t bode well for my adaptation efforts.
Cant do join on influxql 
but flux does joins but being deprecated
I will be a great disservice to thousands of users of this great product and a blemish on influx to just pull the rug out of people that have made your product an integral part of their stack without providing a bridge to cross over to the other side.
1 Like
3.0 has a fully capable SQL engine, which can do joins. We really would have preferred to bring Flux forward in 3.0, but unfortunately, it just isn’t possible with the resources we have available.
We received regular feedback from a majority of potential users that Flux was a blocker for their adoption of InfluxDB. We heard this feedback and added SQL support to help a broader audience adopt. In order to support Flux that requires an entire team building a scripting language, VM, query parser, planner, optimizer and executor and everything that entails. It is simply too much for our team to do when combined with also building the core database.
Over the coming years we’ll do everything we can to help people transition over. But we also continue to provide security updates and critical fixes, which means users that prefer Flux can continue to use 2.0 for years to come.
2 Likes
That’s really sad. Flux is extremely powerful and flexible, it’s really one of the key features of InfluxDB.
3 Likes
Just to clarify @yosiasz and @pauldix my understanding of The future of Flux | Flux Documentation is that flux is still supported on influx3, but its not being actively developed.
I moved to Influx3 cloud serverless to overcome the cardinality limits of Influx2 and all the Grafana dashboards I had created in flux more or less just worked when I pointed at Influx3, many using joins and obscure flux functions. The main issue I hit was with use of [_value] =~ /some|regex/ which doesn’t seem to work immediately after filtering a _field, but does work after a group.
Should Influx plan to stop supporting flux altogether, my hope is that anything I need to see realtime in Grafana I can port to InfluxQL. Anything I need to join and use obscure flux functions on, I’m probably better off downsampling anyway, which I’ve been using python/influxql/pandas to do in the absence of “continous queries” in Influx3.
I agree through, for me flux was the betamax of video but everyone wanted vhs. Yes, I’m quite old.
Thanks!
2 Likes
@thopewell You can also use SQL to perform joins. I’d also check out quix which we’ve partnered with to replace CQs and Flux tasks :).
Quix InfluxDB plugins:
Anomaly detection example with Quix:
Anomaly detection and forecasting with Quix, MQTT, Telegraf, and Huggingface 
1 Like
Flux was a state of art. It’s so sad that you’re abandoning it.
People will embrace InfluxDB 3 for the sake of HA. It’s destined.
You could have focused contributing to Grafana for a handier Flux interface instead of returning to InfluxQL.
I adore Flux tbh.
1 Like
