I have 25+ years of experience in querying relational databases with SQL. As I started using InfluxDB 3 years ago I learned about the limitations of InfluxQL and decided to get used to FLUX. I hate it until today, to be honest
Now, on coincidence, I read about Flux being in âmaintenance modeâ and further read thinks like: âIf you are interested in transitioning to InfluxDB 3.0 and want to future-proof your code, we suggest using InfluxQL.â. But InfluxQL still does not allow to proper join tables as far as I know. Windowing by calendar months and years is a must have for me as well â not supported in InfluxQL. You even have to use a âv1â API if you want to use InfluxQL. All of that does not feel like the way to go to meâŠ
I like InfluxDB. A lot. But how should I build my queries now to be safe for future updates? Is there any alternative I am not aware of? Did I get something wrong here? I am puzzled, can anybody help me out?
I understand why it would be confusing as weâre in an awkward transitionary state right now. If youâre on our Cloud Serverless or Cloud Dedicated platforms, which are based on InfluxDB 3.0 bits, you should use either InfluxQL or SQL.
If youâre on open source, the only options currently available are 1.x and 2.x which both support InfluxQL and Flux. My recommendation there is to use InfluxQL if you wish to make your use of query language portable to InfluxDB 3.0 open source.
We will have a release of InfluxDB 3.0 open source (called InfluxDB Edge) later this year and it will support InfluxQL and SQL natively. That will be through new APIs and for InfluxQL, we will support the v1 API. So youâll be able to point to it as though it is a 1.x InfluxDB server. Although some things like Continuous Queries and SELECT INTO wonât be supported, most everything else in InfluxQL will be.
Weâre going to continue running InfluxDB 1.x and Cloud 2.x for our customers for many years to come. So there are commercial options that give official support for InfluxQL and Flux.
Flux is too large and complicated to be able to bring it over to InfluxDB 3.0 at this time. We were able to bring InfluxQL over because of its similarity to 3.0âs native query language, SQL. We may be able to create an API bridge at some point in the future, but weâre currently more focused on delivering a great 3.0 experience that supports SQL and InfluxQL.
Thanks for your reply, that is very appreciated! I am on Cloud Serverless currently. Trying to start with SQL or InfluxQL.
On:
is says:
âActivate the SQL Sync toggle in the Schema Browser pane to build your SQL query as you select fields and tag valuesâ
But there only is a âFluxSyncâ toggle there for me.
Thatâs right, if you signed up in 2022, youâre still on the Cloud2 product which is based on TSM. Weâre in the process of building migration tools for people in Cloud2 that want to migrate over to IOx, but that wonât be available until later this year. You could migrate yourself by signing up for a new account, which would be IOx based and then writing scripts to copy your data over.
Sorry, but I donât think this answers OP main question : how to do things that are possible with Flux and not with InfluxQL today like joins ? Will they be available in InfluxDB 3 in the future ? If not, are you removing some main features from InfluxDB on purpose ?
Joins are possible in InfluxDB 3.0 today with SQL. And our SQL implementation gets new functions and features on a regular basis. We may be adding features like joins to InfluxQL in the future, but itâs not currently on the roadmap or prioritized.
As for arbitrary processing inside the database, weâll be evaluating bringing in an existing VM, likely Python or possibly Javascript. Itâs on our roadmap, but that is a feature that is pretty far in the future as implementing something like that in a distributed database can be quite tricky. Easy enough to do for a quick example, very hard to do for use cases at scale.
Thanks for all these helpful replies. Interesting discussion evolved here
I myself built and maintained a software company for 20+ years, I totally understand these âtransitionary stateâ issues⊠I added a new org meanwhile. That runs on âStorage Engine Version 3â now. I will try to manually migrate the data and use SQL to access it afterwards. Fingers crossed
I know adding SQL must be a hell of a job, but I am so glad this decision was made as I was about to give up on InfluxDB and was about to ditch it because of the horrible query language I had to learnâŠ
I was considering building some kind of horrible monster with Redis and MySQL memory tables, triggers and stored procedures.
Iâm so glad I donât have to waste my life on both of those things anymore. I will wait for InfluxDB 3 to mature and Iâve been able to test it before I replace trusty old 1.8.
