InfluxDB’s Three-Language Problem

Chait Diwadkar
Chait Diwadkar
/
Share on LinkedIn

Imagine how a WordPress developer might feel if the next major version of WP dropped all PHP support in favor of Ruby, forcing all themes and plugins to be rewritten in the new language or be stuck on an outdated version forever. What do you think Windows administrators would say if Microsoft suddenly moved from PowerShell to Bash, and they had to update all their scripts to work on the next update?

If you’ve been using InfluxDB for a while, you don’t need to imagine. It’s already happened to InfluxDB customers — not once, but twice.

A State of Flux

When InfluxDB was first launched back in 2013, it used InfluxQL as its query language. InfluxQL is a SQL-like language built for time-series use cases, and though its syntax is similar to SQL, it is much less flexible with fewer possibilities for data aggregation and transformation.

With the release of InfluxDB 2.0 in 2020, the Flux language was introduced. Flux is more powerful than InfluxQL, but it is also more complex: users say that they needed to take courses in the “InfluxDB University” to get an understanding of the language, and that they were involved in three or more Flux projects before feeling comfortable with the language. Nevertheless, InfluxDB was confident that Flux would be the way forward, and many of its faithful users went through the process of translating their queries and rewriting their applications to make use of Flux.

Little did they know that only 4 years later, with InfluxDB 3.0, Flux would be deprecated in favor of SQL. Users who spent time learning Flux and updating their projects to use it were rewarded with the inability to upgrade those projects past InfluxDB 2.x and the knowledge that the time spent on Flux was wasted.

While we at TDengine agree with InfluxData that SQL is indeed the best choice for time-series databases, we wish that they had come to that conclusion before wasting their community’s time on other languages.

from(bucket:"power")
|> range(start:-1h)
|> filter(fn:(r) =>
r.measurement == "smeter" and
r.field = "voltage" and
r.location = "chicago"
)
|> aggregateWindow(every: 1m, fn: mean)
SELECT AVG(voltage) FROM power.smeter WHERE ts > now -1h AND location = "chicago" INTERVAL(1m);

Comparing the same query in InfluxDB’s Flux (left) and TDengine’s SQL (right) demonstrates the simplicity and readability of SQL.

TDengine’s Commitment to SQL

SQL has stood the test of time; since its conception 50 years ago, it quickly became the query language of choice for the top database management systems and a powerful tool for database administrators and users. At present it’s not an overstatement to say that almost everyone involved with data – from data science graduates looking for their first job to industry veterans who have been in the field for decades – has some working knowledge of SQL.

TDengine has supported standard SQL from day one and is fully committed to the language: its SQL implementation will only be expanded going forward and never replaced by any other query language.

While supporting standard SQL, TDengine also includes time-series-specific extensions to the language, like rollups, interpolation, and time-weighted averages, meaning that you benefit from the flexibility of SQL plus specialized functions like InfluxQL. In fact, almost everything in TDengine – features like stream processing and data subscription, permissions management, cluster management, and more – is performed with SQL statements.

This support greatly reduces the learning curve for people new to TDengine, as anyone who has used other SQL databases in the past will feel at home with TDengine’s syntax. We believe that SQL is the best path forward for time-series data, and we respect developers’ time too much to require them to learn a specialized toy language just to work with our product.

Furthermore, at TDengine, we understand that stable, long-term solutions are essential for any industrial data infrastructure, and customers want a consistent product experience instead of big pivots every few years. Many users have determined that the workload of upgrading legacy InfluxDB projects to 3.0 is similar to that of simply migrating to another time-series database product altogether, and we invite them to try out TDengine OSS or TDengine Cloud and experience for themselves how easy it is to get up and running.

  • Chait Diwadkar

    Chait Diwadkar is Director of Solution Engineering at TDengine. Prior to joining TDengine he was in the biotechnology industry in technical marketing, professional services, and product management roles and supported customers in pharma, medical devices and diagnostics on analytical chemistry, and genetic platforms.