InfluxData Blog - Gary Fowler

Visualizations with InfluxDB 3: More Options Than Ever Before

Gary Fowler (InfluxData) — Wed, 08 Oct 2025 08:00:00 +0000

We’ve been working on a number of items here at InfluxData to give you even more options for creating visualizations and dashboards for your time series data in InfluxDB 3.

Grafana integration: easier than ever

For advanced visualization needs, we continue to recommend Grafana as the gold standard. The good news? It’s now easier than ever to connect Grafana with InfluxDB 3, thanks to significant improvements made by our friends at Grafana.

The Grafana team has enhanced its InfluxDB connector and data source, streamlining the configuration process for InfluxDB 3. What used to require multiple steps and careful configuration is now more straightforward than ever. You can find detailed setup instructions in both Grafana’s documentation and our own InfluxDB 3 integration guides.

But we didn’t stop there. We’ve added powerful features to InfluxDB 3 Explorer to make Grafana integration even smoother:

Automatic Grafana Data Source Setup: The InfluxDB 3 Explorer now features a Grafana integration that automatically configures your InfluxDB 3 data source in Grafana, eliminating manual setup steps.
Export to Grafana: Once you’ve crafted the perfect query in InfluxDB 3 Explorer, you can export it directly to Grafana, preserving your query logic and saving valuable development time.

These improvements mean you can go from data exploration in InfluxDB 3 Explorer to production dashboards in Grafana faster than ever before.

Native dashboard capabilities: for everyone else

While Grafana remains our recommendation for advanced visualization, we recognize that not everyone uses Grafana or wants to manage a separate dashboarding tool. So, we also created options for these users.

Cloud Serverless Dashboards

We’ve enabled native dashboard capabilities in our InfluxDB Cloud Serverless product. Cloud Serverless customers now have access to visualization dashboards directly from their Cloud UI, providing immediate insights without requiring external tools. This built-in dashboarding gives you quick access to your most important metrics right where you manage your data.

InfluxDB 3 Explorer Dashboards

InfluxDB 3 Explorer has evolved beyond just query exploration. With version 1.3 of InfluxDB 3 Explorer, we are introducing dashboard capabilities, enabling you to create and manage simple dashboards directly within the UI.
InfluxDB 3 Explorer is compatible with all of our InfluxDB 3 products:

Query Mode: Available with all InfluxDB 3 products for data exploration and basic visualization, including InfluxDB 3 Core (open source), InfluxDB 3 Enterprise, InfluxDB Cloud Serverless, and InfluxDB Cloud Dedicated.
Admin Mode: Available with InfluxDB 3 Core & InfluxDB 3 Enterprise for full query and visualization, along with general InfluxDB 3 administration.

This means whether you’re running InfluxDB 3 in the cloud or on-premises, you have access to built-in visualization capabilities with the InfluxDB 3 Explorer tool.

Power BI integration: Enterprise visualization

For organizations already invested in the Microsoft ecosystem, we’re excited to introduce the new InfluxDB 3 Connector for Power BI. This connector opens up the full power of Microsoft’s business intelligence platform for your time series data.

Power BI users can now seamlessly connect to their InfluxDB 3 instances and leverage Power BI’s advanced analytics, custom visualizations, and enterprise reporting features. This integration brings InfluxDB 3 data into the familiar Power BI environment, making it easier for business users to create compelling reports and visualizations. This InfluxDB Power BI Connector is currently available in beta/preview. You can find detailed setup instructions and download links in our InfluxDB 3 integration guides.

Chronograf support: for our InfluxQL community

We haven’t forgotten about our long-time users who rely on InfluxQL and Chronograf for their data processing workflows. We’re currently working on an update to Chronograf to support InfluxDB 3 products. We expect to make that update available before the end of the year.

This improvement ensures that existing Chronograf users can continue leveraging their established alerting and data processing pipelines when transitioning to InfluxDB 3.

Recap

InfluxDB 3 users now have more visualization options than ever before, including:

Advanced, customizable dashboards → Grafana with enhanced InfluxDB 3 integration
Quick, built-in visualization → Native dashboards in Cloud Serverless and InfluxDB 3 Explorer
Enterprise business intelligence → Power BI with the new InfluxDB 3 connector
Existing workflow compatibility → Updated Chronograf support for InfluxDB 3

Ready to explore your data in new ways? Check out the documentation links above and start visualizing your time series data with the tools that work best for your team.

Want to get started with InfluxDB 3 visualizations? Visit our documentation to explore setup guides for each of these visualization options.

Introducing the InfluxDB 3 MCP Server: Natural Language for Time Series

Gary Fowler (InfluxData) — Wed, 09 Jul 2025 07:30:00 +0000

Time series data underpins all real-time systems. From high-resolution telemetry to long-range trends, it’s essential for monitoring, automation, predictive maintenance, and operational insight. But it’s also hard to work with: high cardinality, shifting schemas, and time-based queries make even basic tasks feel heavy.

To address that complexity, we built the InfluxDB MCP server, an open source service that connects InfluxDB 3 to AI tools like Claude Desktop using the Model Context Protocol (MCP). It exposes InfluxDB 3 operations over a standardized interface, so you can query data, inspect schema, and manage your database using natural language, without plugins or glue code. As a result, it makes time series data as easy to work with as it is to describe.

The server is available under both the MIT and Apache 2 licenses, and you can run it alongside your LLM agent (such as Claude Desktop), connecting it to the tools you already use.

Manage time series infrastructure without the overhead

Time series workloads involve more than just querying—you’re constantly managing schema, storage limits, and ingestion pipelines. The MCP server helps simplify that complexity by letting you handle core administration operations through natural language. This includes:

Database Operations: Create, update, and delete databases with proper validation. Cloud Dedicated users can configure advanced settings, such as table limits, column constraints, and retention policies, directly through natural language conversations.
Explore Schemas: Ask questions like, “What measurements do I have in my production database?” or “Show me the schema for the sensor_data table,” and get immediate answers.
Manage Tokens: For Core and Enterprise installations, manage admin tokens, create resource-specific tokens with granular permissions, and handle token lifecycle, all through conversational interfaces.
Health Monitoring: Check connection status and receive troubleshooting guidance when issues arise.

Because it’s wired into your InfluxDB 3 instance, the server translates these prompts into valid operations using the same APIs you’d call directly:

“Create a new database called ‘iot_sensors’ with a 30-day retention period.”
“List all my databases and show me their configurations.”
“Create a read-only token for the analytics team to access the metrics database.”

Query time series data without writing SQL

Beyond management tasks, the MCP server supports time series data querying through natural language prompts. It analyzes your schema and generates SQL queries with appropriate filters, rollups, and limits. This enables:

Exploratory Analysis: AI can examine your data structure, identify patterns, and suggest relevant queries without you needing to know the exact table schemas.
Complex Query Generation: Describe what you want to analyze in natural language, and the AI will generate SQL queries, including proper aggregations and time-based groupings, that work efficiently with InfluxDB’s time series optimizations.
Automated Reporting: Set up conversations that regularly analyze trends, detect anomalies, or generate summaries of your time series data.

Examples:

“Analyze temperature trends from my sensors over the last week and identify any unusual patterns.”
“Compare this month’s API response times to last month and show me the 95th percentile differences.”
“Find all measurements that haven’t received data in the past 24 hours.”

Run it locally. Stay in control.

The InfluxDB MCP server is designed to run entirely on your machine or local infrastructure. It uses your existing InfluxDB 3 token for authentication—no data is sent to external services. You define which databases are accessible by configuring the server with appropriate tokens and permissions.

The server works with the following InfluxDB 3 products:

InfluxDB 3 Core (open source)
InfluxDB 3 Enterprise (self-managed)
InfluxDB 3 Cloud Dedicated (fully managed)
InfluxDB Cloud Serverless
InfluxDB Clustered

You can run it locally using npm or Docker. Just provide your InfluxDB 3 URL and token via environment variables, and the MCP server handles the rest. It’s lightweight and easy to deploy, whether you’re working in a simple local environment or running in production.

Open source and community-driven

The InfluxDB 3 MCP server is designed to be simple, open, and easy to modify. It’s a lightweight bridge between InfluxDB and AI tools, built to make AI-assisted database operations as natural as having a conversation.

You can find it on GitHub. If you hit issues or want to extend it, open a PR or file an issue. We’ll continue to improve it as the ecosystem evolves.

Handling Partial Writes in InfluxDB 3

Gary Fowler (InfluxData) — Thu, 19 Sep 2024 08:00:00 +0000

We recently adjusted how we handle “partial writes” with our InfluxDB Cloud Serverless product using the v2 Write API. This only applies to InfluxDB Cloud Serverless customers (those who created their Cloud accounts after January 31, 2023). In the near future, we will make this change for InfluxDB Cloud Dedicated and InfluxDB Clustered customers as well.

Partial writes will now always return a 400 status code. In most cases, you don’t have to do anything but be aware of the behavior. If you are using the v2 Write REST API directly, make sure your code handles 204 and 400 return codes and know that with a 400, it doesn’t mean all lines didn’t make it (the good lines will be written). Read on if you want more information and background on this change.

What are partial writes?

Most commonly, data gets written to InfluxDB in “batches,” meaning several lines at once. If there are lines within that batch that can’t be written for some reason, we refer to this as a “partial write.”

What conditions can cause a partial write?

The most common condition that causes a partial write is an error in the Line Protocol. Batch lines are formatted in the line protocol format, which requires a specific syntax. If there is an error in that syntax for a specific line, that line cannot be written.

What status code is returned on a partial write?

The status code for partial writes is now always 400.

What was it before?

With Cloud Serverless, a 204 could be returned in some cases. This matched the behavior in Cloud2. In Cloud2, data is first written to an ingestion queue (we used Apache Kafka), and then, as a secondary action, the data is written to the database. Not all line protocol errors can be detected when data is written to the ingestion queue (e.g., schema inconsistencies). Therefore, we acknowledge we have received the data and return a 204 response before it is fully validated. When the data is validated, if there is a problem with any write lines, those lines are written to a separate Cloud 2 bucket (_monitoring) so customers can see and correct any problematic lines. This “_monitoring” bucket does not exist with Cloud Serverless/InfluxDB , so it didn’t make sense to continue returning this status code on a partial write.

Partial Writes were not supported by default in InfluxDB Cloud Dedicated or InfluxDB Clustered, but for customers for whom we had enabled them, the status code could sometimes be a 201.

What else is returned upon a partial write?

When a 400 is returned, it also returns the first 100 failed lines in the batch—so, if there is an exception of just a few lines, your code can know which lines failed.

Future

Our plan is not to make any additional changes to this. However, we do have a v3 Write API planned that will completely revisit this, hopefully add a few more options, and handle partial writes better overall. We don’t plan on deprecating the v2 Write API; you can still use both (you can still use v1, in fact). This will be a new v3 option with more capabilities—including some new data types (teaser alert).

Contact our sales team to get started with InfluxDB Cloud Dedicated or Clustered.

Choosing a Client Library When Developing with InfluxDB 3.0

Gary Fowler (InfluxData) — Fri, 18 Aug 2023 07:35:00 +0000

A common question we get asked is “what client library should I use with InfluxDB 3.0?”

This question isn’t as simple as it may seem. It can get confusing when deciding which client library to use while developing applications to write to and query from InfluxDB. There are numerous options to choose from and the answer may differ based on the following criteria:

the version of InfluxDB you currently use or used in the past
the type of APIs you are looking for (query, write, management)
the query language you want to use (SQL, InfluxQL, Flux)

Today, there are three versions of InfluxDB client libraries available:

v1 Client Library
v2 Client Library
v3 Lightweight Client Library

At first, this seems like an easy answer. Use the v1 Client Library with InfluxDB 1.x; use the v2 Client Library with InfluxDB 2.x; and use the v3 Lightweight Client Library with InfluxDB 3.0, right? Uh, kinda, sorta, no, maybe?

Ok, well, you might be thinking that instead of making a decision based on the version, you should base it on your preferred query language. In other words, if you want to use InfluxQL, use the v1 Client Library; if you want to use Flux, use the v2 Client Library; and if you want to use SQL, use the v3 Lightweight Client Library? That is sort of accurate as well, but still not completely the case in all situations.

The v3 lightweight client libraries

We call the v3 client libraries “lightweight” because they only implement the two functions that most of our customers use: query and write. And we focused on the five languages our customers most commonly use with InfluxDB: Python, Golang, Java, JavaScript, and C#.

The v1 and v2 APIs provided administrative APIs as well (create databases, set retention periods, etc.). InfluxDB 3.0 separates data plane and control plane tooling, so you perform administrative functions within the InfluxDB 3.0 Cloud UI (if using InfluxDB Cloud Serverless) or the influxctl command line utility (if using InfluxDB Cloud Dedicated or InfluxDB Clustered).

Unless your application relies on the administrative APIs, the Lightweight Client Libraries should be all you need.

For new InfluxDB customers that have not already written applications using the v1 or v2 client libraries, the v3 Lightweight Client Libraries are the best choice.

It is not, however, your only choice. You can actually choose “none of the above” and use Apache Arrow Flight for querying and the REST API for writing instead.

The Apache Arrow Flight Library

One option for querying InfluxDB 3.0 is to use the Apache Arrow Flight framework. InfluxDB 3.0 utilizes Apache Arrow and the Apache Arrow ecosystem (Arrow, DataFusion, Flight, Flight SQL, Parquet). This means you can use any Apache Arrow Flight client to query InfluxDB over gRPC. The v3 Lightweight Client Libraries also use Arrow Flight, so technically, you are using it either way.

Apache Arrow Flight is a high performance client-server framework built upon gRPC and the IPC format. The InfluxDB 3.0 implementation of Flight allows you to query using SQL or InfluxQL by simply changing the language flag within the Flight ticket. Flight utilizes the Arrow in-memory columnar data format. When you retrieve data via Flight, you get columnar data, similar to a pandas DataFrame, that you can efficiently query, analyze, and transform using third-party tools like pyarrow and pandas for Python or Polars for Python, JavaScript, and Rust.

Here are some examples of the nifty things you can do with the Flight library and Python:

So if you decide to use Apache Flight directly (instead of using the v3 Lightweight Client library), you might be asking, “Is Apache Flight the only thing I need?” In a blog post devoid of yes or no answers, we have to answer again, “maybe”. If you only need to query, then yes, the Apache Flight library may be the only thing you need.

Many customers fall into this category because they use the InfluxDB Telegraf agent to ingest (write) data into the database and they only query data programmatically. But if you also need to write data to InfluxDB from within your application code, you’ll find the InfluxDB client libraries very convenient for writing and querying.

You can use both the Arrow Flight library and one of the v1/v2/v3 client libraries together so you could simply use Arrow Flight for querying and the v3 lightweight library for writing. But for most circumstances, using the v3 Lightweight Client Libraries is your best bet, because they already utilize Flight and enable both query and write. As mentioned previously, the v3 Lightweight Client Library uses Arrow Flight, it just makes it a little simpler to use because you don’t have to learn Flight. Instead, the libraries allow you to focus on just the query and write functions with InfluxDB 3.0.

One additional note on this: the Arrow Flight Framework for Python is the most advanced. You will find it easier to use with Python than with the other languages it supports.

The v1 Client Libraries

Some of our existing customers ask, “If I’m using a v1 Client Library today, do I need to convert my code to use the v3 Lightweight Client Library when I move to an InfluxDB 3.0 platform (InfluxDB Cloud Serverless, InfluxDB Cloud Dedicated, InfluxDB Clustered, or, eventually, OSS 3.x)?”

In nearly all cases, the answer to this is “No”. You can continue to use the v1 Client Library for InfluxQL queries and for writes. At one point in our past, we steered customers away from the v1 Client Library, encouraging them to use the v2 Library instead. We are no longer doing that because the v1 Client Libraries are compatible with InfluxDB 3.0. This makes it easy for customers to upgrade to InfluxDB 3.0 without having to change a lot of code.

The other reason to consider the v1 Client Libraries is that they support additional languages over v3, including C++ and PHP. So if you need to use these languages, the v1 Client Library may be your best choice.

The v2 Client Libraries

Ok, as we established above, you can use the v3 Lightweight Client Libraries, the Apache Arrow Flight framework, or the v1 Client Libraries with InfluxDB 3.0. But, what about the v2 Libraries?

Here is where things get a little murkier. The v2 Client Libraries and the v2 Query API (which the v2 libraries use) utilize the Flux query language. While some of our customers love this Influx-developed query language, the majority of our customers said they just don’t have time to learn a new query language and really want us to support SQL. While we were disappointed, we did understand. As a result, we developed InfluxDB 3.0 to support SQL and our time series variation, InfluxQL.

The v2 API is not available for InfluxDB Cloud Dedicated and the upcoming InfluxDB Clustered and OSS 3.0 flavors of InfluxDB 3.0. This means you need to use either the v3 Lightweight Client Library, the Arrow Flight Framework, the v1 Client Library — or some combination thereof — when you move to InfluxDB 3.0.

For InfluxDB Cloud Serverless customers, there is a compatibility layer we can enable for some customers that allows v2/Flux API calls to work in some cases. However, because we optimized InfluxDB 3.0 for SQL and InfluxQL, this compatibility is a translation/conversion and requires re-sorting and other operations to deliver the data in the same format and order that it would come in with previous versions of InfluxDB.

Long story short, the performance isn’t there with the v2 libraries in InfluxDB 3.0. Depending on the volume of data and the breadth of query, you could see timeouts and other anomalies with the v2 libraries. Because of this, we only recommend doing this while you are migrating your workloads to one of the other libraries and your queries from Flux to SQL or InfluxQL.

Still confused or unclear after all of this? Refer to this recommendation table:

Customer Type	Product	Recommended Language	Recommended Query Library	Recommended Write Library (if not using Telegraf)	Recommended Admin tool
Brand New Customer using InfluxDB for first time	InfluxDB Cloud Serverless	Use SQL or InfluxQL	Use v3 Lightweight Client Library; Apache Arrow Flight is another option	Use v3 Lightweight Client Library	Use Cloud UI
	InfluxDB Cloud Dedicated, InfluxDB Clustered, OSS 3.0	Use SQL or InfluxQL	Use v3 Lightweight Client Library; Apache Arrow Flight is another option	Use v3 Lightweight Client Library	Use influxctl command line utility
Existing Customer using InfluxQL and v1 Client Library	InfluxDB Cloud Serverless	Use InfluxQL	Use v1 Client Library for existing apps, Consider v3 Lightweight Client Library or Apache Arrow Flight for future applications	Use v1 Client Library for existing apps, Consider v3 Lightweight Client Library for future applications	Use Cloud UI
	InfluxDB Cloud Dedicated, InfluxDB Clustered, OSS 3.0	Use InfluxQL	Use v1 Client Library for existing apps, Consider v3 Lightweight Client Library or Apache Arrow Flight For future applications	Use v1 Client Library for existing apps, Consider v3 Lightweight Client Library for future applications	Use influxctl command line utility
Existing Customer using InfluxQL and v2 Client Library	InfluxDB Cloud Serverless	Use InfluxQL or SQL	Use v2 Client Library ONLY for short term compatibility (if you can’t avoid it); move to the v3 Lightweight Client Library, Arrow Flight, or the v1 Client Library as soon as possible	Use v2 Client Library ONLY for short-term compatibility (if you can’t avoid it); move to the v3 Lightweight Client Library, Arrow Flight, or the v1 Client Library as soon as possible	Use Cloud UI
Existing Customer using InfluxQL and v2 Client Library	InfluxDB Cloud Dedicated, InfluxDB Clustered, OSS 3.0	Use InfluxQL or SQL	Use the v3 Lightweight Client Library, Arrow Flight, or the v1 Client Library; the v2 Client Library and v2 API will not work	Use the v3 Lightweight Client Library, Arrow Flight, or the v1 Client Library; the v2 Client Library and v2 API will not work	Use influxctl command line utility

You can find the v3 Lightweight client libraries at the following locations:

For a deeper dive on the Python v3 Client Libraries, check out this blog from my colleague Jay Clifford.

Now Available: The Flight SQL Plugin for Grafana

Gary Fowler (InfluxData) — Tue, 25 Apr 2023 01:00:00 +0000

Today we have exciting news for Grafana customers with Flight SQL data sources: Now there is a new community plugin available for Grafana that allows it to communicate with Flight-SQL-compatible databases.

Flight SQL is a client-server protocol developed by the Apache Arrow community for interacting with SQL databases. It utilizes the Flight RPC framework and the Arrow in-memory columnar format.

InfluxDB 3.0 supports Flight SQL, which means that you can now use this community plugin to query an InfluxDB 3.0 database. InfluxDB 3.0 is available for new accounts utilizing InfluxDB Cloud Serverless and InfluxDB Cloud Dedicated.

InfluxData helped develop this Grafana plugin in an effort to advance the open source Apache Arrow project, and all products that utilize Apache Arrow and Flight SQL should be able to take advantage of it.

Setting up Grafana Cloud to use Flight SQL is simple

First, select the “+Connect data” button:

Then choose Integrations: Click the “View All” button and then type “Flight” in the search bar:

Next, click on the Flight SQL tile to install the plugin:

To configure the plugin, enter your hostname and port and paste in your API token. Then configure the key and value for your metadata. This consists of ‘bucket-name’ and the actual name of the bucket/database that you are trying to access:

Once you have everything configured, you can start querying data in InfluxDB using SQL and create visualizations using your new data source.

A big thank you to our friends at Grafana for publishing this community plugin for Flight SQL customers.

To try it for yourself, sign up for a free InfluxDB account today.

InfluxDB Cloud Features New Query Experience

Gary Fowler (InfluxData) — Mon, 05 Dec 2022 07:00:00 +0000

If seeing is believing, then the new UI for the InfluxDB query experience is sure to convert you. We are working on a new query/script editor and want you to try it out. Feel free to share your feedback with us so we can make it even better!

Here are just some of the highlights of the new editor.

Schema browser

The new query/script editor includes a schema browser that allows you to see a hierarchical view of your schema. You can select data directly in that schema view and build Flux queries based on those selections.

Schema selections ← → Flux synchronization

This new interface displays auto-generated Flux code to the user at all times. This is different from the existing Data Explorer interface where users must choose between the visual query builder and the script editor. If they choose the visual representation, then the Flux script that InfluxDB creates is completely hidden from the user.

The new editor always shows the user that auto-created Flux code so that they can start to see what it looks like and, when they’re ready, they can add to that code directly, without the need to toggle to a different window. But if you have not (or don’t want) to learn Flux, you still don’t have to. You can still make selections from the schema browser to build your query.

After you make selections in the schema to build (or start) your Flux script, you can add your own custom Flux code below the schema “composition” block. At the same time, you can continue to use the schema browser to make changes to the code in the composition block. The Flux script within the schema composition block stays in sync with the selections in the schema browser. You can toggle this feature on/off using the Flux Sync toggle. If you manually edit the code in the composition block section, Flux Sync automatically deactivates.

By showing the actual Flux script to the user at all times, we hope that users become more comfortable with Flux so that it’s easier to build more complex queries/scripts later on.

Instructional interface

The new query experience represents the basic hierarchy (tags and fields associated with measurements contained within buckets) within the schema browser to help you learn the InfluxDB data model.

One piece of feedback that we received from the user community is that not everyone at a given organization understands the InfluxDB data model. There may be one or more individuals who do, but when they start to pull in others from their organization, those unfamiliar with InfluxDB sometimes struggle, especially if they’re used to working with traditional relational databases. Sometimes new users don’t know where to start when querying InfluxDB. This can lead to queries that return huge datasets, and an overall poor initial experience with InfluxDB.

The new interface represents the hierarchy in a familiar tree format. This helps users refine and narrow their initial queries so that they return more helpful datasets. In addition, the new interface provides in-app help to identify and define the elements of InfluxDB and its data model (e.g., buckets, measurements, tags, and fields) so new users can start off with an accurate foundational understanding of what they’re looking at.

Load/save

The new script editor allows you to save your queries/scripts and retrieve them later. Loading and saving Notebooks is already a production feature, but the capability was unavailable for queries written in the basic Data Explorer until now.

The initial feature is very basic and simple: it allows you to store and retrieve queries/scripts created in the new interface. However, we plan to add version management, cloning, renaming, and folder or label organization in the future, as well as the ability to share your queries/scripts with other users in your organization.

New defaults

This script editor defaults to a table result view of non-aggregated data, something many of you asked us to implement. Pivoting your results by time is another default coming soon.

You can now filter/search on your results without having to run an additional query. Sometimes running a query looking for something very specific returns more results than intended. This feature lets you apply filters to that initial result set, so you don’t have to rewrite your query or write a new, additional query to narrow down your results.

New time range selection

The new Time Range Selector makes it easier to set custom time ranges and provides more flexibility for relative ranges.

Query statistics

The new experience shows you how long your query took to run and how many tables and rows are in the result set.

Multi-language support

While Flux is the first language we are implementing in this new interface, it won’t be the last. Spoiler alert! We are working on SQL support next.

Improved performance and large dataset handling

We improved the performance of displaying tables and working with large datasets. We increased the max result size from 27MB to 100MB and no longer truncate CSV downloads (you can get the entire query set).

More future features

There are many more planned features for the new query/script editor, including adding features like aggregations, group-by, sorting, and “count” function helpers to the interface. Nevertheless, we wanted to get this out and make it available to you now while we continue to work on these items. Doing so also gives us a chance to collect your feedback so we can build the features you actually want, without having to guess.

You can preview the new script editor from a toggle at the top of the Data Explorer window.

We look forward to your feedback as we continue to add features to the new query/script editor.

The Best Query Language to Use with InfluxDB

Gary Fowler (InfluxData) — Mon, 21 Nov 2022 07:00:00 +0000

People often ask us, “What is the best query language to use with InfluxDB?” The answer to this question has evolved a bit over the years – and the current answer might surprise you.

The early days

InfluxDB’s first query language was InfluxQL. InfluxQL is a SQL-like language with some enhancements specifically designed for time series data.

It was far and away the best query language to use with InfluxDB because it was the only query language you could use with InfluxDB. It is very popular and still in use today.

Flux arrives

Even with the success of InfluxQL, we recognized that our users would benefit from something more advanced than SQL-like querying. We wanted something that allowed our customers to perform operations right at the database level. So we built a complete scripting language called Flux. You can do all sorts of things with Flux like:

Combining data sources by pulling in or referencing data from a relational database using the sql.from function
Writing back to a relational database using the sql.to function
Performing simple or complex downsampling or aggregations
Making outbound API calls to trigger action(s) in your own applications

We continue to be very excited about Flux (check out the Flux 1.0 announcement!) and consider it a real differentiator for us. At the same time, we recognize that Flux isn’t necessarily for everybody. It has a learning curve and not everyone is willing to invest the time it takes to learn the language. But if you ask an Influxer, we’d probably tell you that Flux is the best query language to use with InfluxDB.

InfluxDB IOx

With our recent announcement of InfluxDB IOx, we introduced native SQL querying language support as well.

For organizations with IOx-enabled buckets, you can choose from InfluxQL, Flux, and SQL to query your data. So, since we announced SQL support, does that mean that SQL is the best language to use with InfluxDB? The answer, as it often is: it depends.

So what do I choose?

We are bullish on SQL as a query language in InfluxDB and feel it is a great choice in many circumstances, like:

You’re migrating code that already makes PostgreSQL calls to a different SQL database.
You know SQL really well and don’t have time to learn a new tool.
Your primary needs involve querying data and data transformations, and other operations are not as important at this time.

But InfluxQL still has its place and is good in many other situations, like:

You like the SQL-like experience but want the time series extensions that come with InfluxQL.
You already wrote a lot of query scripts using InfluxQL and don’t want to migrate them.
You love InfluxQL!

And Flux is certainly a winner when you want a full-fledged scripting language that can do advanced operations at the database level beyond what you can do with a simple query language.

Rather than recommending or promoting a specific language, we continue to abide by our mantra of “meeting developers where they are.” When it comes to querying data in InfluxDB, we give you multiple options, in the hope that at least one of those options is right for you based on your own environment and work experience. And it isn’t always about choosing just one query language. Some users may want (or need) to utilize a combination of the supported query languages.

But we aren’t simply content with these three language options either. For writing tasks that run on the InfluxDB platform, we also plan to add support for Python and Javascript. This will give you even more options for creating tasks and let you leverage your existing skills in the process.

So, while you might have expected me to say that Flux is the best query language to use (we do think it is really awesome), or maybe you thought I would say SQL is the best query language to use because our IOx engine supports it, I am not. Those are, in fact, two terrific options, and InfluxQL is a third. The bottom line is that you know your environment best and probably already have a good idea of what the best fit is for you. With that in mind, my official recommendation to you is:

The very best query language to use with InfluxDB is whatever you choose to use.