Is Flux being deprecated with InfluxDB 3.0?

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 :frowning:
but flux does joins but being deprecated :frowning:

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.

2 Likes