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.
@pauldix @Jay_Clifford Thanks for the blog post and clarity.
For the real time graphing use cases I’d like to keep on using flux but for some of the other processing where I was using flux, it looks like support for Influx3 in the influxdb-client along with pandas might actually be easier/better than flux (I’m not hands on with python day to day so I hadn’t fully explored this). I just got a downsample AWS lamda working against my diff() use case - I’d be happy to contribute a post on this somewhere since I had to pull in bits and pieces from a few different Influx resources.
Thanks,
Tom
I prefer flux in “tasks” and “alerts” because SQL cannot perform better stream logic processing
Flux lives on and Fluxpipe v1.0.0 supports read/write for InfluxDB 3.0 APIs and native FlightSQL!
Existing queries should continue working, and you can now execute them anywhere you desire as a service emulating the InfluxDB API, as a serverless function, within your github action or just locally on your system with zero overhead cost. Releases are based on the Flux Community fork and available as containers and statically compiled binaries. All we need is users and feedback.
This concern is now obsolete. If you love Flux, join the Fluxpipe community on github and help us keep Flux alive and kicking for years to come!
Oh boy I will be a very active user and I will give feedback as soon I could get my hands on Influx 3.0 OSS 
There are some InfluxDB 3.0 community builds available to use under the same github organization and they appear to be working although now that IOx source code is no longer accessible you might want to wait for InfluxDB Edge builds instead.
Question about future-proofness wrt down-sampling: Shall I go for an InfluxDB v1 or v2 setup?
I am about to setup several databases/buckets to capture sensor data from my smart home, to build some Grafana dashboards on top. Detailed data for couple of weeks/months, downsampled for the long-term. Nothing spectacular, but will require some efforts (partially learning project :)).
Understood from Paul’s blog and above that Flux will continue to work, but not first choice it seems.
Downsampling with buckets in v2 also seems to be a bit less smooth in combination with Grafana than with v1 (if I understand the interweb correctly).
Given the focus on InfluxQL/SQL in v3, I was wondering whether an SQL-based v1 setup with retention policies might be easier to migrate to InfluxDB Community in the future, to limit time needed.
Thanks!
From everything I’ve read so far, it looks like that’s a yes. But nothing is ever set in stone.
@pauldix Hi Paul, curious what your view is on this topic. Thanks so much!
