I am lost: which query language to use!?


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 :wink:

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?

Thanks in advance,

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.


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.

What can I do?

When did you sign up for Serverless and which cloud/region are you on?

2022, I am on https://us-east-1-1.aws.cloud2.influxdata.com

Meaning I still am on TSM and need to migrate to IOx…?

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 :wink:

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 :upside_down_face:

Splendid news!

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.

I am on v3 serverless now and it works.

BUT: It is not possible to delete any data besides dropping the whole bucket!? Seriously? Is there an ETA for delivering this core feature?