Would it be possible to outline in some sort of document where the gaps are? So that the community can start doing the due diligence of assessing the effort?
(As others have pointed out, the size of the flux codebase currently in production isn’t trivial. Re-writing these from scratch will correspond to potentially hundreds of man hours that might be spent doing something useful instead)
I’ll see if we can get someone to outline what a rough plan would look like. I think it will end up being a significant effort, but if we can help enable the community to help themselves, I think that would be great.
For anyone interested, Fluxpipe is a fully functional serverless Flux runner and API based on the Flux community fork which will be focused on Community contributions and extensions. It should be able to pick up a good variety of Flux tasks and interact with external datasources as an independent worker:
We’re slowly working on a basic FlightSQL driver (mostly) for the InfluxCommunity Flux fork, based on the latest InfluxDB 3.0 libraries and focused on reading, which despite not being ideal will be fully functional and hopefully help many transition from Flux to native FlightSQL usage over time… or not at all. If anyone would like to join us and help make this happen faster, please reach out.
Hello @Anaisdg ,
I just wanted to sanity check something.
Our current data sits in an organisation with version:
InfluxDB Cloud powered by TSM Storage Engine Version 2 (e6bbae1)
I copied over some of this data to a new organisation I set up via the UI at version:
InfluxDB Cloud Serverless Storage Engine Version 3
Is this Influx3.0?
I pointed an instance of Grafana at v3 and all of the widgets seem to work (they’re all written in Flux). So I assume flux is backwards compatible for now? and will be deprecated in the future?
Like many others, I feel there are some things I can do in flux that we won’t be able to do in sql. It’s my intention to write up a page on this somewhere in the community. But a really simple use case would be:
|> filter(fn: (r) => r["_field"] =~ /_counter/)
I can add new fields something_counter and I don’t have to touch the code that downsamples the data as a counter (get the difference between records). I can’t find an sql equivalent, it seems I have to be specific about the fields I select - thats a bunch of extra code to maintain everytime a field is added to the data (which I don’t neccesarily control) for something that just worked before in flux!
Thanks,
Tom
The community has done it! Flux(pipe) now supports FlightSQL queries to InfluxDB IOx 
This is great news 
. Can you explain a bit further as to how one can use this? For example, if we are running Influx IOx Cloud right now and want to use Flux queries, how is that done?
I think the SQL equivalent will be
WHERE _field LIKE('%_counter%')
but yeah, all your post is still valid, and I totally agree ( I just thought that you’ll find that information useful).
Thanks for the info @fercasjr!
@pauldix I think we need some official guidance on moving from TSM to Influx3.0 for customers that have been on TSM for a long time but want to take advantage of Influx3.0 performance. It seems a lot of features have just dissapeared from the UI, I always thought iox or Influx3 was going to be TSM+.
I need unlimited cardfinality so am keen to move to Influx 3.0, but I have to refactor all the tasks and alert endpoints set up via Influx stacks to terraform/lambda.
I found this: TL;DR InfluxDB Tech Tips: Downsampling with Flight SQL and AWS Lambda | InfluxData which I assume I can modify to use flux… I also need to understand how long my flux queries will continue working via the current api before I need to refactor those to sql (where possible).
I’m still fustrated flux is potentially being deprecated, it seemed like the query language of the iot future. In focusing on sql, perhaps Influx can capture more of the market currrently on postgress type databases, but it also opens up the door for existing customers to move off Influx. When I report that I need to refactor a bunch of stuff to take advantage of Influx3.0, I’m being asked to compare Influx3.0 to alternative databases like AWS timesstream say.
I don’t want to move, but it does seem strange to introduce a new product missing some fundamental features of the predecessor!
Thanks,
Tom
I am on the exact same situation.
I am already at capacity on the server I use (this server was intended for one thing but eventually I ended up with the requirement to add more stuff to it). I already optimized every single one of my queries, and at this point Influx DB 3.0 sounds very promising… but I don’t know If I will have the bandwidth to refactor everything (And also, I don’t want to do it).
Today I put up a blog post about our plan for InfluxDB 3.0 open source. I also spend quite a bit later in the post talking about Flux and what happened there and what the path forward may be. Read the whole thing or just scroll down to the heading about Flux: The Plan for InfluxDB 3.0 Open Source | InfluxData
I’m happy to answer follow on questions from that.
Thanks. I saw the post earlier and read it completely… man it was kind of confusing with all those versions 
but I appreciated the effort put in to to trying to clarify.
Hi @fercasjr, thanks for checking out the blog in full 
. We are hoping to deliver follow-up content as these offerings develop. As trying to explain each new edition in one blog was a lot 
.
A way to think about things is that we have two main product lines:
My plan is to delve into the self-hosted options in later content.
