InfluxData Blog - Developer

A Guide to Downsampling Time Series Data with InfluxDB 3

Charles Mahler (InfluxData) — Wed, 19 Aug 2026 08:00:00 +0000

This tutorial demonstrates both approaches using the InfluxDB 3 Processing Engine’s built-in bird tracking simulator plugin. You will generate telemetry, aggregate it into 10-second windows, and validate the result with SQL. The same pattern works for infrastructure metrics, industrial sensors, application telemetry, and other time series workloads.

Why downsample time series data?

High-resolution data is valuable while diagnosing a recent event, but its value often changes as it ages. A temperature reading collected every second may be useful for an active incident, while a daily report may only need 10-minute or hourly averages.

Downsampling helps you:

scan fewer rows in long-range queries
make dashboards over weeks or months more responsive
retain useful historical trends at a lower resolution, reducing storage costs
calculate common summaries once instead of repeating the work
keep raw data only for as long as its full resolution is useful

Downsampling is not the same as deleting raw data; it creates a summarized view or table at a lower granularity. Retention is a separate decision and process where data is fully deleted after a set period of time.

Choose Query-Time or Persisted Downsampling

InfluxDB 3 gives you two practical patterns for downsampling:

Approach	How it works	Best for	Main tradeoff
Query-time SQL	Uses `DATE_BIN` and aggregate functions in a `SELECT` query	Exploration, flexible dashboards, and changing aggregation requirements	Recomputes the result each time and does not reduce stored raw data
Python Processing Engine	Runs the official downsampler plugin on a schedule and writes aggregate rows to a target table	Repeated long-range queries, predictable rollups, and tiered retention	Requires you to choose aggregates and scheduling behavior in advance

A useful starting point is to develop and validate an aggregate in SQL. If the same query becomes a frequent or expensive workload, then use the downsampler plugin.

Prerequisites

To follow this tutorial, you need:

InfluxDB 3 Core or Enterprise with the Processing Engine enabled
InfluxDB 3 CLI installed and connected to the server
An authorization token with permission to create a database and triggers
Outbound access to GitHub so InfluxDB can load the official plugins referenced by gh: paths

The examples assume a database named bird_demo:

influxdb3 create database bird_demo

If you are using the local Docker environment that accompanies this article, InfluxDB is available at http://localhost:8181. InfluxDB 3 Explorer is available separately at http://localhost:8888 for running the SQL and capturing visual results.

Generate Sample Telemetry with the Official Bird Simulator

InfluxData’s bird data simulator is a convenient fit for this tutorial. It creates repeatable time series behavior without requiring a separate data generator or hardware sensor.

The plugin writes to the bird_tracking table. Its tags include species and name, and its fields include body_temp, longitude, latitude, speed, and heading.

First, install the plugin’s Faker dependency:

influxdb3 install package Faker

influxdb3 create trigger \
  --database bird_demo \
  --path gh:influxdata/bird_data_simulator/bird_data_simulator.py \
  --trigger-spec every:1s \
  --trigger-arguments bird_count=10 \
  bird_tracking_demo

After the trigger has run for several seconds, confirm that data is arriving:

SELECT *
FROM bird_tracking
ORDER BY time DESC
LIMIT 5;

At one write per bird per second, the simulator produces approximately 600 rows per minute for 10 birds.

Downsample at Query Time with SQL

InfluxDB 3 SQL supports time bucketing with DATE_BIN(). The following query groups the raw bird readings into 10-second intervals and calculates speed and body-temperature statistics for each bird:

SELECT
  DATE_BIN(INTERVAL '10 seconds', time) AS time,
  species,
  name,
  AVG(speed) AS avg_speed,
  MIN(speed) AS min_speed,
  MAX(speed) AS max_speed,
  AVG(body_temp) AS avg_body_temp,
  COUNT(*) AS record_count
FROM bird_tracking
WHERE time >= now() - INTERVAL '2 minutes'
GROUP BY 1, species, name
ORDER BY 1 DESC, species, name;

DATE_BIN aligns each timestamp to a 10-second boundary. GROUP BY 1 refers to the first expression in the SELECT list while species and name preserve one series per bird.

This is true query-time downsampling: the server returns fewer, summarized rows, but it does not write them to another table. Change the interval or aggregates whenever the question changes. For example, a long-range dashboard might replace INTERVAL '10 seconds' with INTERVAL '1 hour'.

Always include a bounded time predicate. It reduces the data scanned and makes the query’s intended resolution explicit.

Persist Downsampled Data with the Python Processing Engine

For an aggregate that many users or dashboards repeatedly request, calculate it on a schedule with InfluxData’s official downsampler plugin. The plugin queries the source table, computes aggregates, and writes the results to a target table.

This trigger creates one average speed and body-temperature row per bird for every 10-second interval:

influxdb3 create trigger \
  --database bird_demo \
  --path gh:influxdata/downsampler/downsampler.py \
  --trigger-spec every:10s \
  --trigger-arguments \
  'source_measurement=bird_tracking,target_measurement=bird_tracking_10s,interval=10s,window=2min,offset=10s,calculations=speed:avg.body_temp:avg,specific_fields=speed.body_temp' \
  bird_tracking_downsample

The trigger arguments control the rollup:

source_measurement is the raw source table.
target_measurement is the table that receives aggregates
interval=10s defines the time-bin width.
calculations assigns an aggregate function to each field
specific_fields limits processing to the fields needed by this rollup.
offset=10s delays the queried window so its newest bin has time to close.

Why the Offset Matters

The offset is not cosmetic. Without it, the simulator and downsampler could execute on the same 10-second scheduler boundary. Without an offset, the downsampler may query the newest bin while writes are still arriving, producing partial aggregates.

With offset=10s, the preceding completed bin and every aggregate in the validation window should have the expected 10 source points. In production, set the offset to at least the maximum delay you expect between an event occurring and becoming queryable. Workloads with late or out-of-order data may need a larger offset and lookback window.

Inspect the Persisted Result

The downsampler names calculated fields by appending the aggregate function, so speed becomes speed_avg and body_temp becomes body_temp_avg. It also writes record_count, time_from, and time_to metadata.

The plugin stores the data with nanosecond precision and converts it with TO_TIMESTAMP_NANOS() when you want readable timestamps:

SELECT
  time,
  species,
  name,
  ROUND(speed_avg, 2) AS avg_speed_mph,
  ROUND(body_temp_avg, 2) AS avg_body_temp_c,
  record_count,
  TO_TIMESTAMP_NANOS(time_from) AS source_start,
  TO_TIMESTAMP_NANOS(time_to) AS source_end
FROM bird_tracking_10s
ORDER BY time DESC, species, name
LIMIT 20;

Sample Output

Time (UTC)	Species	Bird	Avg. speed	Avg. body temp.	Source points	Source start
2026-08-14 21:21:00	American Robin	Tracy	22.47	41.94	10	21:21:00
2026-08-14 21:21:00	Blue Jay	Sara	21.59	41.67	10	21:21:00
2026-08-14 21:21:00	Cactus Wren	Brandon	18.78	41.74	10	21:21:00
2026-08-14 21:21:00	Great Blue Heron	Brenda	6.38	41.10	10	21:21:00
2026-08-14 21:21:00	Great Blue Heron	Pamela	24.97	41.35	10	21:21:00

Validate the Reduction with SQL

Do not judge a downsampling job only by whether the target table contains rows. Compare a fixed, completed interval so active writes cannot change the counts during validation.

The following query compares two completed minutes of source data with the corresponding persisted rollups. Replace the timestamps with a completed interval from your own run:

WITH raw AS (
  SELECT COUNT(*) AS raw_rows, COUNT(DISTINCT name) AS birds
  FROM bird_tracking
  WHERE time >= TIMESTAMP '2026-08-14T21:20:00Z'
    AND time " TIMESTAMP '2026-08-14T21:22:00Z'
),
downsampled AS (
  SELECT
    COUNT(*) AS downsampled_rows,
    SUM(record_count) AS represented_raw_rows,
    AVG(record_count) AS avg_points_per_row
  FROM bird_tracking_10s
  WHERE time >= TIMESTAMP '2026-08-14T21:20:00Z'
    AND time " TIMESTAMP '2026-08-14T21:22:00Z'
)
SELECT
  raw_rows,
  birds,
  downsampled_rows,
  represented_raw_rows,
  avg_points_per_row,
  ROUND(
    100.0 * (
      1.0 - CAST(downsampled_rows AS DOUBLE) / CAST(raw_rows AS DOUBLE)
    ),
    1
  ) AS row_reduction_percent
FROM raw CROSS JOIN downsampled;

Example Output

The equality between raw_rows and represented_raw_rows is an important completeness check. The 90% figure is a reduction in rows for this query shape, not a promise of an identical reduction in bytes on disk. Actual storage depends on schema, tags, fields, compression, and retention settings.

You should also compare aggregates against the query-time SQL version before applying any raw-data retention policy.

Downsampling best practices for production

The tutorial uses short intervals so you can see results quickly. A production workload might keep second-level raw data briefly, create 5-minute summaries for operational dashboards, and return hourly summaries for long-term reporting.

When designing that pipeline:

window=2min gives each execution a lookback window large enough to reprocess recent data.
Start with the questions users need to answer, then choose the interval. A bin that is too wide can hide short-lived behavior.
Preserve the tags you need for filtering and grouping. Removing a dimension during aggregation cannot be reversed later.
Select aggregates that match the signal. Gauges often need average, minimum, and maximum; counters may need sums or rates.
Account for ingestion delay with offset, and use a lookback window that can catch expected late data.
Validate counts and values over multiple completed intervals before shortening raw-data retention.
Monitor the Processing Engine logs and query latency after deployment.

Troubleshoot a scheduled downsampler

If the target table remains empty, inspect the Processing Engine logs:

SELECT
  trigger_name,
  log_level,
  log_text,
  event_time
FROM system.processing_engine_logs
ORDER BY event_time DESC
LIMIT 20;

Then check the most common causes:

The source table or a field name does not match the trigger arguments.
The source does not contain data within the plugin’s window and offset.
A Python dependency required by a plugin has not been installed.
The server cannot retrieve a remote gh: plugin.
The selected aggregate is not valid for a field’s data type.
The newest interval is incomplete because the offset is too small.
Getting started with downsampling with InfluxDB 3

InfluxDB 3 makes it possible to use the same SQL aggregation logic at two stages of a workload: interactively at query time and operationally as a persisted rollup. Start with DATE_BIN to confirm the right interval and dimensions. When the query becomes a stable, repeated access pattern, schedule the official Python downsampler and include an offset so it works on completed data.

Try the tutorial with InfluxDB 3 and the official InfluxDB 3 plugin library. Once your results match the raw source over a completed interval, adapt the interval, aggregates, offset, and retention strategy to your production workload.

FAQs

What is downsampling?

Downsampling is the process of grouping time series points into wider time intervals and calculating summaries such as averages, minimums, maximums, sums, or counts. InfluxDB 3 can calculate those summaries at query time with SQL or persist them with a Python Processing Engine.

How do I downsample data with InfluxDB 3 SQL?

Use DATE_BIN to place timestamps into fixed intervals, apply aggregate functions such as AVG or MAX, and group by the binned time plus any tags you want to preserve. SQL downsampling returns aggregate rows but does not automatically write them to another table.

When should I use the Python Processing Engine instead of SQL alone?

Use the Processing Engine when you want to precompute and store a rollup on a schedule. It is a good fit for aggregates used repeatedly by dashboards or long-range reports. Use query-time SQL when you need flexible intervals, are still exploring the data, or do not want another stored representation.

How do I prevent partial downsampling windows?

Set the downsampler plugin’s `offset` so it queries intervals that have finished receiving data. The offset should cover normal ingestion latency and expected late arrivals. Validate completeness by comparing the sum of `record_count` in the aggregate table with the raw row count over the same closed interval.

Does downsampling delete the original data?

No. Both a SQL aggregate query and the downsampler plugin leave the source data intact. The plugin writes additional rows to a target table. Raw-data deletion or expiration is controlled separately through retention settings.

What does record_count mean in the downsampled table?.

`record_count` is the number of source records represented by an aggregate row. It is useful for detecting incomplete bins and for comparing the target table with the source over the same period.

Can I calculate more than one aggregate per interval?

Yes. A SQL query can return multiple functions such as AVG(speed), MIN(speed), and MAX(speed) in the same group. The official downsampler accepts calculation mappings for multiple fields. Choose only the summaries your queries need to avoid unnecessary write and storage overhead.

Does this approach work with InfluxDB 3 Cloud Serverless or Cloud Dedicated?

The embedded Python Processing Engine workflow in this tutorial applies to InfluxDB 3 Core and Enterprise. For InfluxDB Cloud Serverless, follow the documented client-library downsampling pattern: query aggregates with SQL, write the results back, and schedule the client externally. For Cloud Dedicated, you can use the same general query-and-write pattern with an InfluxDB 3 client library and an external scheduler.

How much storage will downsampling save?

There is no universal percentage. The tutorial reduced the number of rows returned for its fixed test window by 90%, but byte-level storage depends on the schema, data types, tag cardinality, compression, the aggregates stored, and how long you retain each resolution.

A Rust Client for InfluxDB 3

Ian Clark (InfluxData) — Thu, 13 Aug 2026 08:00:00 +0000

Time series data shows up wherever the physical world meets software. A satellite constellation streams altitude, power, and thermal telemetry from every spacecraft on every pass. A factory floor running on Industry 4.0 principles instruments every line, every motor, every batch. And underneath all of it sits a humbler problem that anyone who has worked in operational technology knows well: getting telemetry out of the PLCs and edge controllers that actually run the machines, off the bus, and into a database that can enable real-time asset intelligence.

InfluxDB 3 is built for this class of workload. It is the latest generation of the InfluxDB time series engine, built on an open source stack: Apache Arrow for in-memory columnar data and Apache DataFusion as the query engine. In practice, that means InfluxDB 3 is a columnar, vectorized engine that speaks SQL, exchanges data over Arrow Flight, and interoperates with the broader Arrow ecosystem, rather than a closed world with its own bespoke query path. For high-cardinality telemetry (thousands of spacecraft channels, tens of thousands of sensor tags on a plant floor), that columnar foundation is what keeps both ingest and analytical queries fast.

What has been missing for Influx users is a first-class Rust client. We just built one: influxdb3-client, an async Rust client for InfluxDB 3 Core and Enterprise that mirrors the feature set of the official Go and Python clients with an idiomatic Rust API.

Why Rust, when Go and Python clients already exist?

The honest answer is that for a lot of jobs, you shouldn’t switch. If you’re exploring data in a notebook, the Python client is the right tool. If you’re writing a typical backend service, the Go client is mature and perfectly fast. Rust earns its place in the parts of a telemetry pipeline where the other two start to fight you. Here are some scenarios where it makes sense to switch:

The edge box next to the PLC. The machine that bridges OPC UA or Modbus to your historian is often an ARM gateway with a few hundred MB of RAM, no package manager you control, and a change window measured in months. Rust cross-compiles to a single static binary, with no Python interpreter to install and patch on the box and no runtime to ship. scp it over, run it for a year.

Ingest where tail latency is the spec. During a ten-minute satellite pass, the ground segment has to drain every frame the downlink produces; there is no catching up later. A garbage collector that pauses at the wrong moment turns into dropped telemetry. Rust’s lack of a GC doesn’t make your code faster on average; it makes the worst case boring, which is what you actually care about when the data source won’t wait.

Backpressure you can reason about. High-rate ingest lives or dies on flow control: how many batches are in flight, how much memory they pin, what happens when the database slows down. With tokio, that’s an explicit semaphore and bounded buffers checked by the type system, rather than a goroutine count you tune by load testing.

The telemetry source is already Rust. Increasingly, the code producing the telemetry is Rust: a ROS 2 node on an autonomous mobile robot, drone flight software, a soft-PLC runtime, or a protocol bridge that speaks OPC UA or MQTT-Sparkplug. When the producer is a Rust process, the historian client should be a library you embed in it: same binary, same async runtime, no sidecar process to deploy and monitor on every robot in the fleet. An Arc"Client" shared across your tokio tasks is the whole integration.

Compile once, use anywhere. The same binary often has to write to whatever InfluxDB the customer runs. As of 0.2, writes default to the V2 /api/v2/write endpoint, so one client works unchanged against InfluxDB 3 Core and Enterprise as well as InfluxDB Clustered and Cloud Dedicated/Serverless. A config flag, not a code change, opts into the V3-only extras like no_sync when you control the server.

You’re already in the Arrow ecosystem. InfluxDB 3 itself is written in Rust on Arrow and DataFusion. With this client, query results come back as native Arrow RecordBatches—the same types you’d hand to DataFusion, Polars, or your own analytics code, with no serialization boundary in between. The client and the server are speaking the same in-memory format end-to-end.

If none of these scenarios describe your situation, the Go and Python clients remain great choices. If one of them does, you should get familiar with the Rust client.

Installation

The client is on crates.io and requires Rust 1.89 or later:

cargo add influxdb3-client

Or add it to your Cargo.toml alongside an async runtime:

[dependencies]
influxdb3-client = "0.2"
tokio = { version = "1", features = ["full"] }

There is an optional polars feature for DataFrame-based workflows, which we’ll come back to later.

Let Claude Write the Boilerplate

If you use Claude Code, there’s an influxdb3 skill that teaches it the InfluxDB 3 API surface: line protocol, the v3 SQL and InfluxQL query paths, token and database administration, and the client libraries—this one included. With the claude-influxdb3 plugin installed, you can skip the docs-spelunking and ask things like:

*"Write me a Rust snippet that writes a batch of sensor readings to my InfluxDB 3 cluster and reads the last hour back with SQL."*

You’ll get working code against this client’s actual API. It also knows the troubleshooting terrain: 401s from token scoping, line-protocol parse errors, and queries that silently return no rows. That’s most of what a first hour with any database consists of.

Configuring a client

uuA client needs a host, a database, and (usually) an API token. This is the most explicit way is to build the configuration yourself:

use influxdb3_client::{Client, ClientConfig};

#[tokio::main]
async fn main() -> influxdb3_client::Result"()" {
    let client = Client::new(
        ClientConfig::builder()
            .host("http://localhost:8181")
            .token("my-api-token")
            .database("sensors")
            .build()?,
    )
    .await?;
    Ok(())
}

For deployments where configuration comes from the environment, such as a container or a systemd unit on an edge box, read INFLUX_HOST, INFLUX_TOKEN, and INFLUX_DATABASE directly:

let client = influxdb3_client::Client::from_env().await?;

Optional variables (INFLUX_AUTH_SCHEME, INFLUX_ORG, INFLUX_PRECISION, INFLUX_GZIP_THRESHOLD, and the INFLUX_WRITE_* family) configure the same write defaults the builder exposes, so a deployed agent can be retuned without a rebuild.

Or, parse a single connection string, which is handy when configuration arrives as a single opaque value:

"let client = influxdb3_client::Client::from_connection_string(
    "https://cluster.example.io/?token=TOKEN&database=mydb",
).await?;

The Arrow Flight channel used for queries is opened lazily on the first query, so constructing a client never blocks on query connectivity, and a write-only ingest agent never pays for a query connection it won’t use.

Writing data

client.write(data) returns a builder; chain the options you want, then .await it. The data argument is flexible—it can be a line-protocol string, a Vec"Point", or (with the polars feature) a DataFrame.

Points

The Point builder is the most ergonomic way to construct measurements in code:

use influxdb3_client::{Point, Precision};

let points = vec![
    Point::new("temperature")
        .tag("location", "office")
        .tag("floor", "2")
        .field("celsius", 22.5_f64)
        .field("humidity", 48_i64)
        .field("occupied", true),
];

client.write(points).precision(Precision::Millisecond).await?;

Raw Line Protocol

If you already have line protocol, say forwarded straight off a device, you can write it as is:

client
    .write("cpu,host=server01 usage_user=42.3,usage_system=1.2")
    .await?;

Write Options

The builder exposes the knobs that matter for real ingest pipelines:

client.write(points)
    .precision(Precision::Nanosecond)
    .batch_size(10_000)          // points per HTTP request
    .max_inflight(8)             // concurrent in-flight requests
    .default_tag("region", "us-east")
    .tag_order(["region", "host"])
    .await?;

Large inputs are split into batches and sent as multiple pipelined requests, with one batch buffer held in memory at a time, so memory stays bounded even on very large writes.

tag_order matters more than it appears to. The first write defines the physical tag column order for a table, and that order affects query performance; tags you filter on most should sort first. .tag_order(...) serializes the listed tags first, then appends any remaining tags in deterministic lexicographic order, so the machine that happens to boot first doesn’t accidentally pick a bad layout for everyone. (Background: sort tags by query priority.)

Which Write Endpoint?

As of 0.2, writes go to the V2 /api/v2/write endpoint by default, which means the same client also works against InfluxDB Clustered and InfluxDB Cloud Dedicated/Serverless without changes. Opting into the V3 endpoint (ClientConfig::builder().write_use_v2_api(false), or INFLUX_WRITE_USE_V2_API=false in the environment) unlocks two V3-only behaviours: no_sync() (acknowledge before the WAL is synced) and partial-write reporting, both covered below.

High-Throughput Ingest

For sustained, high-volume writes, such as a satellite pass or a full plant floor, the throughput levers are batch_size (points per request) and max_inflight (concurrent requests per call). On the V3 endpoint (write_use_v2_api(false)), no_sync() adds a third: acknowledge before the WAL is synced, trading a little durability for speed.

A single write call serializes its batches on one task. To use more CPU cores and connections, run several write calls concurrently. A Client is cheap to share, and its HTTP connection pool is reused, so the idiomatic pattern is to wrap it in an Arc, spread chunks across tasks, and cap concurrency with a semaphore to keep in-flight buffers bounded:

use std::sync::Arc;
use tokio::sync::Semaphore;

let client = Arc::new(client);
// cap concurrent writes
let gate = Arc::new(Semaphore::new(8)); 

// each chunk is a Vec"Point"
for chunk in chunks {                    
    let permit = gate.clone().acquire_owned().await.unwrap();
    let client = Arc::clone(&client);
    tokio::spawn(async move {
        // released when the write completes
        let _permit = permit;            
        client
            .write(chunk)
            .batch_size(10_000)
            .max_inflight(8)
            .no_sync()

            .await
    });
}

To spread load across multiple ingest nodes, put a load balancer in front of the cluster, or construct one Client per node and distribute chunks across them.

Querying data

InfluxDB 3 supports both SQL and InfluxQL, and the client exposes both through the same query-builder pattern: client.sql(q) or client.influxql(q).

let result = client
    .sql("SELECT * FROM temperature ORDER BY time DESC LIMIT 10")
    .await?;

for row in result {
    let row = row?;
    let loc = row["location"].as_str().unwrap_or("");
    let c = row["celsius"].as_f64().unwrap_or(0.0);
    println!("{loc}: {c}");
}

InfluxQL is called in exactly the same way, which makes it easy to bring existing InfluxQL queries forward:

let result = client
    .influxql("SELECT MEAN(celsius) FROM temperature WHERE time > now() - 1h")
    .await?;

Parameterized Queries

Bind parameters with .param() rather than interpolating into the query string:

let rows = client
    .sql("SELECT COUNT(*) AS n FROM cpu WHERE host = $host")
    .param("host", "server01")
    .await?
    .rows()?;

if let Some(r) = rows.first() {
    println!("count: {}", r["n"]);
}

Working with Rows

A QueryResult can be iterated row by row, collected all at once with .rows(), or accessed as raw Arrow RecordBatches with .record_batches() if you want to hand the columnar data straight to another Arrow-aware library. A Row is indexed by column name (row["col"]) or position (row[0]), and yields a Value with typed accessors: as_f64, as_i64, as_str, as_bool, is_null.

One deliberate design choice: if a query returns an Arrow type the row API doesn’t support, you get an explicit Error::UnsupportedArrowType, rather than a silent null. Telemetry pipelines fail quietly often enough without the client library helping.

Streaming Large Results

For analytical queries whose results are too large to hold in memory, like a scan over a month of high-rate telemetry, stream the Arrow batches instead of collecting them:

use futures_util::TryStreamExt;

let mut stream = client.sql("SELECT * FROM temperature").stream().await?;
while let Some(batch) = stream.try_next().await? {
    println!("got {} rows", batch.num_rows());
}

Reliability

Telemetry pipelines run unattended, so the client retries transient failures automatically with exponential backoff and full jitter. Connection errors, timeouts, 429, and 5xx responses are retried, and Retry-After is honored when present. Deterministic failures (other 4xx responses and partial writes) are never retried. Retrying writes is safe because line-protocol writes are idempotent at the (series, timestamp, field) level, i.e., re-sending the same point simply overwrites it.

use influxdb3_client::RetryConfig;
use std::time::Duration;

// Per-request override.
client.write(points)
    .retry(RetryConfig { max_retries: 5, base_delay: Duration::from_millis(100), ..RetryConfig::default() })
    .await?;

// Disable retries for a single call.
client.write(points).no_retry().await?;

On the V3 endpoint, when a batch contains invalid lines, the server accepts the valid ones and reports the rest, which surfaces as Error::PartialWrite with the rejected lines attached:

use influxdb3_client::Error;

if let Err(Error::PartialWrite(e)) = client.write(line_protocol).await {
    for line_error in &e.line_errors {
        eprintln!("line {}: {}", line_error.line, line_error.message);
    }
}

If all-or-nothing semantics fit your pipeline better, .accept_partial(false) rejects the entire batch when any line fails.

Polars integration

For data-engineering and analysis workflows, the optional polars feature lets you write a DataFrame directly and read query results back as one:

influxdb3-client = { version = "0.2", features = ["polars"] }

use influxdb3_client::write_dataframe::DataFrameWrite;
use polars::prelude::*;

let df = df![
    "host"    => ["srv1", "srv2"],
    "region"  => ["us-east", "us-west"],
    "cpu_pct" => [42.5_f64, 71.0_f64],
    "time"    => [1_700_000_000_000_000_000_i64, 1_700_000_001_000_000_000_i64],
]?;

client
    .write(
        DataFrameWrite::new(&df, "server_metrics")
            .tags(&["host", "region"])
            .timestamp_column("time"),
    )
    .await?;

let df_back = client
    .sql("SELECT * FROM server_metrics")
    .await?
    .to_polars()?;

Backfilling from Parquet Files

Let’s look at a common migration task. Say you have historical telemetry sitting in Parquet files, exported from another system or batch dumped from a data lake, and you want it in InfluxDB where it can be queried alongside live data. File IO deliberately lives in your code rather than the client; read the file with Polars, then hand the frame to DataFrameWrite. Enable the Parquet reader on Polars in your own Cargo.toml:

polars = { version = "0.53", features = ["Parquet"] }

use std::fs::File;
use polars::prelude::*;
use influxdb3_client::write_dataframe::DataFrameWrite;

let df = ParquetReader::new(File::open("sensors.Parquet")?).finish()?;

client
    .write(
        DataFrameWrite::new(&df, "sensor_data")
            .tags(&["site", "line", "machine_id"])
            .timestamp_column("time"),
    )
    .await?;

Parquet files carry their schema, so dtypes arrive correct—floats stay floats, timestamps stay timestamps. Columns you name in .tags(&[...]) become tags, the timestamp column sets each point’s time, and every remaining column becomes a field. The whole pipeline, from Parquet reader through DataFrame and client to server, is Arrow-native, so the data never leaves columnar form until the final encode.

For a multi-gigabyte backfill, read and write in file-sized chunks rather than one giant frame, and reuse the high-throughput pattern from earlier (batch_size, max_inflight, one task per file) to keep the pipe full.

Loading CSV Exports

Most SCADA packages and historians will export CSV, so it’s often the format you’re handed. The same programming pattern works, with one caveat: CSV carries no schema, so Polars infers column types, and anything ambiguous infers as a string. A string column becomes a string field in InfluxDB, and you can’t MEAN() a string. Supply the dtypes explicitly and parse the timestamp at read time:

polars = { version = "0.53", features = ["csv"] }

use polars::prelude::*;
use influxdb3_client::write_dataframe::DataFrameWrite;

let schema = Schema::from_iter([
    Field::new("machine_id".into(), DataType::String),         
    Field::new("rpm".into(), DataType::Float64),                       Field::new("spindle_load_pct".into(), DataType::Float64),  
    Field::new("alarm_active".into(), DataType::Boolean),     
    Field::new("time".into(), DataType::Datetime(TimeUnit::Nanoseconds, None)),
]);

let df = CsvReadOptions::default()
    .with_schema(Some(Arc::new(schema)))
    .try_into_reader_with_file_path(Some("plc_export.csv".into()))?
    .finish()?;

client
    .write(
        DataFrameWrite::new(&df, "machine_telemetry")
            .tags(&["machine_id"])
            .timestamp_column("time"),
    )
    .await?;

If you’d rather let inference do the first pass, that works too. Just cast() the numeric and boolean columns before writing, or they’ll land as string fields and you’ll be wondering why your aggregation queries return nothing.

FAQ

What is `influxdb3-client?`

The Rust influxdb3-client is a Rust native client library for programmatically interacting with Influxdb. It simplifies writing Line Protocol (Influxdb’s native format) as well writing queries in SQL and Influxql.

What Rust version does it require?

The crate requires Rust version 1.89 or later.

Does it work with InfluxDB Cloud Dedicated, Clustered, or Serverless, or only Core and Enterprise?

Yes! The client library has a full backwards compatible api and integrates with any version of Influxdb that supports the v2 write API.

Does the client support InfluxDB 1.x or 2.x?

Yes. Later versions of InfluxDB have forward compatibility APIs, and all versions of Influxdb support the v2 write API.

Why would I use this instead of the Go or Python client?

Rust excels in embedded programing environments, or integrations with other Rust codebases.

Is the Polars integration required?

No. Polars enables reading and writing to CSV and Parquet files, or if you want to leverage Polars Dataframes, but isn’t required.

Does it retry failed writes automatically?

Yes, the client retries transient failures automatically with exponential backoff and full jitter.

Where do I report issues or request features?

https://github.com/InfluxCommunity/influxdb3-rust

Try it

The repository ships runnable examples in examples/: a quickstart that does an end-to-end write and query, a Cloud Dedicated connection example, and a Polars DataFrame round-trip. Point them at a running InfluxDB 3 instance and go:

INFLUX_HOST=http://localhost:8181 INFLUX_TOKEN=token INFLUX_DATABASE=mydb \
    cargo run --example quickstart

The client is influxdb3-client on crates.io, the source lives on GitHub, and the API docs are on docs.rs. It’s early, and feedback, issues, and pull requests are all welcome.

Where Historians Fall Short for Physical AI

Conrad Chuang (InfluxData) — Tue, 04 Aug 2026 08:00:00 +0000

Physical AI enables machines and industrial systems to perceive conditions, reason about them, and act in the real world. In industrial settings, as part of an industrial AI strategy, physical AI models can help organizations identify risks earlier, optimize operations, and respond to changing conditions in real-time.

Delivering these outcomes starts with training AI models on detailed historical operational data. Then, when deployed, these models need access to real-time telemetry to interpret current conditions, make decisions, and automate actions.

For organizations built around traditional historians, supporting model training and real-time operations creates new challenges and new opportunities.

Where historians fall short for Physical AI

Data historians remain essential systems for industrial operations. They create a durable record of process and equipment behavior, supporting engineering analysis, troubleshooting, reporting, auditability, and, where required, regulatory compliance.

But the issue is, simply put, data historians were built for, well, historical data. The data requirements of Physical AI are different.

At inference time, models need immediate access to current, sufficiently detailed operational data. During development and training, they need consistent, well-labeled history drawn from many operating conditions, assets, and sites. Historian-centered architectures can make both jobs difficult.

Retaining Operational History Versus a Live Model Feed

Data historians are effective at recording operations and helping engineers investigate what happened. But many historian deployments were not designed to continuously serve high-frequency OT data to AI models and applications operating across edge, IT, and cloud environments. The data may be collected in real-time, yet still be difficult to use in real time. Historian data commonly remains inside the OT environment, where access is constrained by network segmentation, security requirements, proprietary interfaces, and site-specific infrastructure. Making it available to an AI application may require gateways, scheduled queries, replication, exports, or additional integration pipelines.

Every additional step introduces operational complexity, and more importantly, delays. At inference time, latency matters. Physical AI systems must evaluate current conditions while there is still an opportunity to respond. If telemetry reaches the model after the equipment state or process condition has changed, the data may still support investigation, but it can no longer support timely intervention.

Compression Removes Relevant Signals for Model Training

Legacy data historians often use techniques such as (deadbands, exception processing, compression, aggregation, or downsampling, to reduce data volume while preserving operational trends. This approach is appropriate for traditional data historian workloads, e.g., reporting, troubleshooting, and compliance.

By comparison, Physical AI models need to be trained on high-resolution telemetry that preserves the patterns required to recognize normal and abnormal operating states, predict outcomes, and determine the appropriate action. When those details are removed before training, models may not be able to learn the subtle behaviors that distinguish one condition from another.

The Cost of Fragmented Data

Legacy data historian architectures were designed in an era when operational technology (OT) and information technology (IT) environments were largely separate. That separation creates challenges when training Physical AI models because much of the context needed to interpret telemetry, such as maintenance records, production schedules, quality results, operator actions, business processes, and asset relationships, resides in IT applications such as ERP, MES, and CMMS systems.

In addition, historian architectures also tend to be site-centric. Historians are typically deployed and managed at the plant, facility, or asset level, creating separate stores of operational history across the organization. Physical AI initiatives may need data from multiple—or even all—sites to build an enterprise-level history that captures a broader range of assets, operating conditions, failures, and outcomes.

Lastly, training datasets for Physical AI models are increasingly multimodal, combining telemetry with inputs such as images, video, audio, and LiDAR. When these sensory inputs are connected and aligned in time, models can learn how observations—across sight, sound, spatial awareness, and machine state—relate to operating conditions, how events unfold, and which outcomes or actions follow. This multimodal training prepares Physical AI models to interpret a wider range of sensory inputs at inference time, reason about current conditions, and ultimately act within the physical world.

The challenge is that legacy historian architectures preserve time series telemetry as an operational record, but they do not inherently connect it with enterprise context, history from other sites, or data held in specialized multimodal systems.

Bridging these data silos requires building ETL pipelines, custom integrations, and manual workflows to align timestamps, asset identities, operating conditions, events, and outcomes. Engineers spend significant time collecting, reconciling, and preparing data before it can be used to train Physical AI models.

The Problem	Historian Limitation	InfluxDB 3 Solution
Inference needs live data	OT data is trapped behind gateways and exports	Ingests at the edge with low-latency queries
Training needs full signal details	Compression, downsampling, and aggregation strip patterns out	Retain and serve full resolution data at scale
IT/OT connection	Context lives outside the historian	Connects telemetry with applications (ERP, MES, CMMS)
AI needs data from every site	Stores data on a per-site basis	Consolidates multi-site data
Models need to learn from more than sensor data	Historians don't line up video, images, or audio with telemetry	Syncs telemetry with other data types by time

A modern time series architecture connects edge and cloud

Fortunately, teams don’t need to rip out their historians and toss them aside. With InfluxDB 3, organizations can build on existing historian investments while creating a more modern operational data architecture for Physical AI. Historians can continue to preserve the operational record, while InfluxDB provides a distributed time series data layer for ingesting, processing, consolidating, and distributing telemetry across edge, cloud, and enterprise environments.

At the industrial edge, time series services can sit close to the source, where teams can process and query live telemetry for low-latency inference and action. Some or all of that data can also be sent to InfluxDB Cloud, creating a common, time-aligned data layer that brings together operational history from multiple sources. This gives organizations the detailed, connected historical datasets needed for model training, evaluation, and enterprise analysis.

The cloud consolidation point also serves as a distribution layer. Telemetry can be made available without building a separate DataOps pipeline or custom integration between each source and every consumer. The same architecture can therefore support local decision-making at the edge and enterprise-wide learning in the cloud.

Even better, this shared data layer can connect telemetry with asset metadata, data from enterprise systems such as ERP, MES, and CMMS, and multimodal data such as images, video, and audio. Time-aligned telemetry provides the operating context for these other data types, showing machine state, load, temperature, vibration, control settings, and process conditions at the moment a multimodal observation was captured or an operator action was taken. The result is a richer training foundation that helps Physical AI models learn not just what happened, but the conditions in which it happened, context that supports more accurate inference, stronger root-cause analysis, and better operational decisions.

Building a Context-Rich Training Dataset for Physical AI

Delivering Live Telemetry to AI at Inference

Built on Apache Arrow and DataFusion with SQL support, InfluxDB 3 enables fast time series queries across large volumes of time-stamped data. It works alongside legacy historians as a real-time time series layer, or hub. Teams can ingest high-frequency telemetry, query recent data as it arrives, and use that data in dashboards, and to trigger alerts and automation workflows. With the Python Processing Engine, teams can process signals, extract features, detect anomalies, and act on data as it arrives. This brings analysis closer to ingestion, helping deployed physical AI models run inference on current operating conditions and respond as they change.

Built for the physical world

Legacy data historians will continue to play an important role in preserving operational history and supporting long-term analysis. But as AI-driven operations become more common, organizations need additional capabilities to make detailed operational data continuously available for training, inference, and action.

By extending historian investments with a modern, distributed time-series architecture, teams can support real-time action at the edge while consolidating and distributing operational data across the enterprise.

Ready to build a stronger foundation for Physical AI? Explore InfluxDB 3 open source with InfluxDB 3 Core or a free trial of InfluxDB 3 Enterprise. For more on this topic, watch the webinar, Physical AI for Industrial IoT: Edge Impulse + InfluxDB.

FAQ

What is Physical AI, and how does it differ from other forms of AI?

Physical AI refers to AI systems that interact with the material world, interpreting telemetry through the lens of physical laws rather than just processing numbers or generating content. In industrial settings, it relies on continuous operational data such as sensor telemetry, machine states, and process conditions to interpret its environment and act in real-time.

What's the difference between a data historian and a time series database?

A data historian is built to record industrial process and equipment data for engineering analysis, troubleshooting, and compliance reporting. A time-series database, like InfluxDB 3, is purpose-built to ingest, query, and act on time series data in real-time across edge, cloud, and enterprise environment. Historians excel at retaining a historical record; time series databases are built to also serve that data live to applications and AI models.

Why can't traditional historians support real-time AI inference?

Many historian deployments store data inside OT environments where network segmentation, proprietary interfaces, and site-specific infrastructure limit real-time access. Getting that data to an AI model typically requires gateways, scheduled queries, or export pipelines, each of which adds latency.

How does InfluxDB 3 help unify data across multiple industrial sites?

Historians are typically deployed at the plant or facility level, creating separate stores of operational history. InfluxDB 3 can consolidate time series data from multiple sites into a centralized or cloud-based layer, giving Physical AI models an enterprise-wide dataset spanning more assets, operating conditions, and failure modes than any single site can provide alone.

What’s New in InfluxDB 3.11: A Significant Performance Upgrade for Complex Time Series Workloads

Peter Barnett (InfluxData) — Thu, 30 Jul 2026 07:30:00 +0000

Time series workloads rarely stay predictable for long. A system might begin with a few devices reporting a small set of measurements. As the fleet grows, new sensors come online, tags multiply, and query patterns change. A table that looked simple at the start becomes wide and sparse. A workload built around recent data expands into long-range analysis. As complexity grows, maintaining fast query performance and a predictable resource profile becomes much harder.

InfluxDB 3.11 was built for that reality.

Our last two releases gave users an early look at a set of performance improvements designed for heavier, more complex time series workloads. Today’s release of InfluxDB 3.11 makes those performance improvements GA in InfluxDB 3 Enterprise, bringing significantly faster queries on live data, greater flexibility for wide and ultra-sparse schemas, and more predictable performance under heavy load. The release also adds new Enterprise capabilities for backup and recovery, bulk data import, row-level deletes, and cluster operations.

Performance and flexibility for heavier, more complex workloads

Faster Reads for Single-Series Workloads

Time series applications rely on fast access to recent data, whether it’s the latest reading from a device, the current state of an asset, a narrow time range from a sensor, or a live view that tracks ingest. For highly selective queries, like those for a single time series, this new release of InfluxDB 3 Enterprise is up to 4x faster than previous versions.

Actual performance will vary by workload, schema, hardware, and query shape. But for industrial monitoring, fleet management, observability, energy systems, and other applications built around live operational data, these gains mean faster access to the current state of the system.

More Room for Wide, Sparse, and Changing Schemas

Time series data rarely arrives in one clean shape. As devices, sensors, tags, and operating environments change, schemas can become wide, sparse, and highly variable. Rigid schema limits can force teams to split data across more tables, drop useful context, or design around the database instead of the application.

InfluxDB 3.11 expands schema flexibility with support for thousands of tables and millions of columns, while efficiently handling ultra-sparse datasets where only a small fraction of fields may be populated at any given time. Teams can model complex, changing telemetry around the data itself, with predictable query performance even as schemas grow wider and sparser.

For customers moving from InfluxDB 1.x or 2.x to InfluxDB 3, this brings forward the schema flexibility they know from InfluxDB, now with the full SQL query engine, object-store-based durability, and unlimited cardinality.

More Predictable Performance Under Load

InfluxDB 3.11 reduces the resource spikes that can occur during heavy ingest and compaction. Memory usage is more predictable, and compaction runs with a more consistent resource profile, making it easier to understand what a workload actually requires.

Teams can size infrastructure with more confidence instead of holding extra capacity for occasional spikes. Query responsiveness stays steadier under load, while memory and infrastructure costs are easier to plan for as workloads grow.

New data management capabilities for Enterprise

InfluxDB 3.11 also adds new Enterprise capabilities for backing up, importing, and deleting data:

End-to-End Backup & Restore: You can now run full or incremental backups to capture compacted data. Restores run asynchronously, providing disaster recovery and allowing you to roll a live cluster back to an earlier point in time.
Bulk Import from Parquet: Bringing existing or external data into InfluxDB 3 is now much simpler. A new bulk-import feature lets you upload an entire directory of Parquet files to ingest the data directly.
Row-Level Deletes: Deleting individual rows is inherently more complex in columnar storage where data is optimized to be written and read in larger blocks. InfluxDB 3.11 now lets you target specific data by time range or tag predicate, without having to drop an entire table.

InfluxDB 3 Explorer UI, now built in

InfluxDB 3.11 brings the Explorer UI directly into InfluxDB 3, giving users a visual interface for querying, exploring, and managing their data out of the box.

Explorer goes well beyond basic data visualization. You can query data using SQL, InfluxQL, or natural language, convert existing Flux queries to SQL with AI-assisted explanations, and manage Processing Engine plugins from the built-in plugin manager. Explorer also includes schema browsing, sample data generation, visualization, and live instance monitoring in one interface.

Get started with InfluxDB 3.11

InfluxDB 3.11 brings the performance improvements introduced in our last two releases to GA, with faster single-series queries, support for wide and ultra-sparse schemas, and more predictable performance under load. New Enterprise data management capabilities and the built-in Explorer UI make these improvements easier to deploy and manage in production.

As time series workloads grow, so do demands on the database. InfluxDB 3.11 is built to maintain performance as complexity increases.

Download the latest version of InfluxDB 3 Core or Enterprise, pull the newest Docker image, or check out the docs (Core, Enterprise) to get started.

AI-Powered Spacecraft Operations with InfluxDB 3

Charles Mahler (InfluxData) — Wed, 29 Jul 2026 08:00:00 +0000

When a satellite is drifting toward a fault, operators don’t need another dashboard full of disconnected charts. They need to know what changed, what it means, and what to check before the next ground pass closes. That’s the idea behind our satellite telemetry demo: a live mission-control experience built on InfluxDB 3.

The demo monitors a simulated fleet of 12 satellites, continuously ingesting telemetry such as onboard computer temperature, battery voltage, solar current, reaction wheel RPM, power draw, RF link margin, ground station, orbit pass, and attitude status. One satellite is actively degrading, while historical incidents provide useful context for comparison.

You can check out the live demo here or watch the video to see it in action:

Demo overview

From Telemetry Stream to Operator Signal

The main dashboard provides a fleet overview showing which satellites are online, which are currently in contact, and where anomalies are occurring. Operators can then drill into individual spacecraft to get a more specific view and look at historical data.

Detecting Anomalies as Data Arrives

Behind the scenes, the InfluxDB 3 Processing Engine observes incoming data as it is written to the database and automatically creates alerts based on conditional thresholds or sensor states.

That means anomaly detection happens without waiting for a separate pipeline to catch up. Another processing engine task incorporates NOAA data for environmental context alongside vehicle behavior.

This pattern can be extended beyond satellites. Any connected system with high-volume and time-sensitive data, such as industrial equipment, energy infrastructure, production systems, or logistics networks, will benefit.

Accessing Operational Truth Using AI

This demo also includes an AI agent powered by the InfluxDB 3 MCP server. Instead of generating answers based on generic knowledge, the agent can access data stored in InfluxDB. You can ask about fleet health, a specific satellite, or the root cause of a suspected issue. The agent can then query InfluxDB throughout a conversation and summarize what it found.

Under the hood: From raw telemetry to operational context

This demo goes beyond the dashboard; it illustrates how InfluxDB 3 can transform live data into enriched operational data without external tools, as well as how to integrate InfluxDB into LLM-powered workflows.

Alerting on Real-Time Data

Each incoming batch of satellite telemetry data triggers a processing engine plugin that evaluates data, such as:

Onboard computer temperature
Reaction wheel RPMs
Power draw
Attitude status

If an anomaly is found, an alert is written to a separate InfluxDB table. The row contains all relevant information for managing an incident, both in the short term and for historical tracking. Instead of the AI agent burning tokens querying and searching raw telemetry, it works from a dedicated alert stream that preserves the signal behind the alert.

Enriching Telemetry with Third Party Data

Another way the demo uses the Processing Engine collecting NOAA planetary Kp index data with an external API call. This data is then stored in InfluxDB where operators can analyze how satellites are being impacted by external conditions and surface any correlated relationship between them.

Scheduled Processing Engine jobs help enrich operational data. Depending on your use case, this could include weather, energy prices, traffic, or financial market data. It can also calculate rollups, forecast, or downsample data at a scheduled interval.

Integrated AI Agent Using the InfluxDB 3 MCP Server

The AI agent is connected to InfluxDB via the MCP server. Rather than relying on a static prompt or blindly summarizing a dashboard, it can query recent telemetry and alerts, inspect the result, and explain its conclusion.

The UI exposes that query/tool trace so operators can see what evidence informed the answer. The agent effectively becomes an interface to your data model.

Putting the processing engine to work

InfluxDB 3’s Processing Engine runs Python inside the database and supports triggers on data writes, schedules, and HTTP requests. That allows it to do far more than simple threshold alerts. You can check the documentation for more detail on the three trigger types and how plugins can retain state between executions.

Here are a few interesting ways you can take advantage of the Processing Engine:

Trigger type	Use case	Outcome
On write	Stateful anomaly detection	Detect drift against a rolling baseline, not just a static threshold.
On write	Schema validation and enrichment	Reject or flag malformed data; add additional metadata.
On write	Alert routing	Write an alert record and then kick off an incident management workflow with related context.
Scheduled	Deadman check	Identify data sources that have stopped writing data.
Scheduled	Forecasting and error evaluation	Generate expected readings, compare them to actual behavior, and detect changes before a hard limit is crossed.
Scheduled	Data lifecycle	Downsample or export selected data.
HTTP request	Operational runbooks	Expose an API endpoint that an app can use to retrieve data or start a workflow.

If you don’t want to start from scratch building with the Processing Engine, there are a number of plugins built and supported by the InfluxDB team. Some plugin examples:

Anomaly detection
Schema validation
Notifications
Iceberg export
Integrations for Kafka, MQTT, and AMQP

The bigger opportunity is to compose these pieces. You could ingest data, validate it on write, detect drift against a baseline, write a contextual alert, enrich it with scheduled external data, and let an MCP-enabled AI agent explain the event in plain language.

Check out the demo and start building

While this demo is built specifically for satellites, the architecture is designed for any use case where time series data is used to take action and direct important decisions.

InfluxDB 3 stores the live signal. The Processing Engine detects, enriches, and routes meaningful events. The MCP server gives an AI agent a grounded way to investigate the data and show its work. Together, they turn telemetry from data teams merely collect into something they can understand and act on.

Resources

FAQs

How does the demo detect anomalies in real-time?

The InfluxDB 3 processing Engine watches incoming data as it is written and automatically generates alerts based on conditional thresholds or sensor states. This removes the need for a separate processing pipeline.

What is the InfluxDB 3 Processing Engine and what can it do beyond alerting?

The Processing Engine allows InfluxDB 3 to run custom Python code inside your database. This code can be activated by three different trigger types: data writes, schedules, or via HTTP request. Beyond threshold alerts, it can be used for schema validation, deadman checks, downsampling, data transformation, and many other use cases.

How can InfluxDB be used with an AI agent?

This demo uses the InfluxDB MCP server to connect to an AI agent, giving the LLM context directly from InfluxDB to answer questions about the current state of the satellite fleet. InfluxDB also has a CLI and REST API that can be utilized by AI agents.

Is this demo specific to satellites or can the architecture be reused elsewhere?

The architecture is designed for any use case built on time series data that is used to drive decisions. It could be used for monitoring industrial equipment, energy infrastructure, or logistics networks. The same combination of InfluxDB for storage, Processing Engine for anomaly detection and enrichment, and MCP for AI-powered investigation generalizes for all of these use cases.

What is InfluxDB 3?

InfluxDB 3 is a time series database used to store and analyze time series data for high performance workloads. It has a built-in Python VM for low latency data analysis and an MCP server for integration with AI agents.

What’s New in InfluxDB 3: 5 New Processing Engine Plugins

Charles Mahler (InfluxData) — Thu, 23 Jul 2026 08:00:00 +0000

The InfluxDB team has released five new Processing Engine plugins. They range from making it easy to call a hosted ML model to pulling in stock market data in real-time. Every one of them can be activated with a few terminal commands. No external services or tools—they all run inside your existing InfluxDB instance.

Here’s what’s new, when you’d reach for them, and a few quickstart examples to get you going in minutes.

Processing Engine primer

If you aren’t familiar, the Processing Engine is an embedded Python runtime inside InfluxDB 3 that allows you to execute Python code on the following triggers:

Schedule - Run code at scheduled intervals
Data write - Runs whenever data is written to a table
Request - A custom HTTP endpoint that handles incoming requests

Plugins can query InfluxDB, transform your data, and write it back to a new table. They can also be used to hit external services outside InfluxDB.

SageMaker inference

The SageMaker plugin pulls rows of data, formats them how your SageMaker model expects, calls the model endpoint, and writes the prediction back to InfluxDB. It can build CSVs or 8 different JSON schema options, so it supports TensorFlow Serving, AWS’ built-in algorithms, and Hugging Face models.

This plugin allows you to use your deployed SageMaker models without having to create a custom plugin. Just point the plugin at your endpoint to get anomaly scores, classifications, forecasts, or whatever else your endpoint returns, and have it written directly to InfluxDB.

Example: Anomaly Scoring with Built-In AWS Model

influxdb3 install package boto3
influxdb3 install package pandas

influxdb3 create trigger \
  --database iot \
  --path "sagemaker.py" \
  --trigger-spec "every:30s" \
  --trigger-arguments 'endpoint_name=rcf-anomaly,source_measurement=metrics,feature_order={cpu}|{mem}|{rps}|{p99_ms},json_shape=instances_features,output_fields=anomaly_score=scores[*].score,interval=2min,limit=20' \
  rcf_score

With this setup, every 30 seconds the last 20 rows of metrics will get batched into a request to your Random Cut Forest endpoint. Each score comes back as a new row in the specified output table.

Value counter

This plugin is a port of the Telegraf value counter aggregator plugin. Point it at a field, and it will count how many times each unique value shows up in your data. It can be used with a data write trigger that counts as rows arrive or a scheduled trigger that aggregates the time window since it last ran. Common use cases for this plugin are HTTP status codes or log-level counts.

Chronos forecasting

The Chronos forecasting plugin allows you to use Amazon’s Chronos time series foundation models directly against your InfluxDB data. Chronos models don’t require a training step; you point the plugin at a measurement, and it returns a median forecast and prediction interval between 50% and 80%. This plugin works as a scheduled trigger for recurring forecasts and as an HTTP trigger for on-demand forecasting.

The benefit of using Chronos models is that you don’t need to mess around with training data or tuning per series. If you want to start getting forecasts on your data as soon as possible, this is the fastest path.

Example: On-Demand Forecast via HTTP

influxdb3 install package chronos-forecasting
influxdb3 install package torch

influxdb3 create trigger \
  --database mydb \
  --path chronos_forecasting.py \
  --trigger-spec "request:forecast_series" \
  chronos_forecast_http

influxdb3 enable trigger --database mydb chronos_forecast_http

curl -X POST "http://localhost:8181/api/v3/engine/forecast_series" \
  -H "Content-Type: application/json" \
  -d '{"table": "sensor_data", "field": "temperature", "horizon": 28, "context_limit": 128}'

This will return your historical context and a 28-step forecast, with each point having a median value and 50%-80% confidence bounds.

Simple data replicator

This plugin replicates data from your local InfluxDB 3 instance to a remote instance over HTTP, with built-in table/field filtering and renaming. It can be run on a schedule or on every data write. Data is buffered in a queue with automatic retries to support unreliable network connectivity.

The data replicator makes it easier to set up edge-to-cloud deployments, sync dev and staging environments, or deploy InfluxDB in multiple regions.

Example: Replicate Data on Every Write

influxdb3 install package influxdb3-python

influxdb3 create trigger \
  --database mydb \
  --trigger-spec "all_tables" \
  --plugin-filename gh:influxdata/simple_data_replicator/simple_data_replicator.py \
  --trigger-arguments host=example.com,remote_token=apiv3_token,database=remote_db,tables="home home2",unique_file_suffix=wxyz5678 \
  simple_data_replicator_trigger

influxdb3 enable trigger --database mydb simple_data_replicator_trigger

Stock portfolio tracker

With the stock portfolio tracker plugin, you can fetch live stock prices from Yahoo Finance. Define the tickers you want to track in a TOML configuration file and monitor values over time. This plugin is mostly an example of how versatile the Processing Engine is, showing how you can make external API calls, aggregate data on a schedule, and roll up your data.

Mix and match your plugins

These five plugins are just some of the most recent created by the InfluxDB team. The official plugin library already has plugins for data transformation, downsampling, anomaly detection, alerting, and more. The biggest benefit of the Processing Engine is the ability to combine these out-of-the box tools. Here is some inspiration:

SageMaker Inference + Notifier - SageMaker writes anomaly scores to InfluxDB as time series data. You can then use the Notifier plugin to send alerts to Slack, email, or a webhook if a threshold is crossed without needing a separate alert stack.
Value Counter + State Change - If you are tracking the status of something, you can use the value counter to tell you how many times a value has appeared and combine it with the state change to tell you when it changed. Together you can track frequency counts and status-change events for alerting, giving you a complementary view of the same data.
Simple data replicator + Downsampler - Downsampling your data locally before sending it to your remote InfluxDB instance will help to reduce bandwidth usage.
Simple data replicator + InfluxDB to Iceberg - This combination allows you to move hot data from InfluxDB to another instance for redundancy or regional access, and then export cold data to Iceberg for long-term storage.

All five are live now in the influxdb3_plugins repository. Grab one, wire up a trigger, and see what you can build with the InfluxDB 3 Processing Engine.

FAQs

Q: Do I need to write Python to use these plugins?

No, each plugin is ready to run after you install its dependencies with influxdb3 install package, then wire it up with influxdb3 create trigger. You only need to touch Python if you want to modify the plugin’s behavior or create a custom plugin.

Q: Do I need to write Python to use these plugins?

Q: Can I configure a plugin with a file instead of inline commands?

Yes, every plugin supports using a TOML configuration file via the config_file_path argument. Using a configuration file is recommended for setups that require more than a few parameters.

Q: Where do I see plugin errors or logs?

Every plugin writes to the system.processing_engine_logs table in the trigger’s database.

Q: Do these plugins work with all versions of InfluxDB 3?

All five run on both InfluxDB 3 Core and InfluxDB 3 Enterprise; you just need the Processing Engine enabled (--plugin-dir /path/to/plugins when you start the server).

Telegraf 1.39 Release Notes

Sven Rebhan (InfluxData) — Fri, 10 Jul 2026 08:00:00 +0000

A new feature-bearing release for Telegraf is now available:

Telegraf 1.39 — Release notes

You can find the binaries for the latest Telegraf release on our Downloads page. Many thanks to all the open source community members who contributed to this effort!

New plugins

These are the newest plugins, first available in this version:

GNMI dial-out input (inputs.gnmi_listener)
- Receive GNMI dial-out telemetry data pushed by network equipment such as Nokia SR OS devices.
- Please open a feature request to request support for your devices.
- Contributed by srebhan

Important changes

Here are some changes to highlight:

OPCUA node discovery
- The OPCUA input plugins, both inputs.opcua and inputs.opcua_listener, can now be configured to discover nodes based on filtering patterns. This allows Telegraf to work in dynamic environments where nodes are added or removed on the server side.
- If configured, the plugin will browse available nodes on the server and filter them according to your settings. It will then subscribe or listen to the remaining nodes to create metrics.
- Use the browse settings to specify the root node and depth for the nodes to discover and one or more browse.paths patterns to filter the nodes found.
Oracle SQL driver support
- Use the outputs.sql plugin to stream metrics to Oracle databases.
- Custom header support for Kafka
- Set custom record headers for messages sent by outputs.kafka. The header values support templating, taking the metrics sent as input.
MongoDB custom metadata
- Set custom metadata in outputs.mongodb for the MongoDB documents written by specifying a tag subset. This allows easier and more efficient querying while keeping the full metric information.
OpenTelemetry improvements
- The outputs.opentelemetry plugin now allows using a proxy or authenticating with a token.
More system details
- The inputs.system plugin provides more details on the host system, such as DMI hardware and operating system information.
- To include this information, please opt in by adding the respective include settings in your configuration.

Downloads

Head to our Downloads page to get the latest Telegraf release. If you have issues or questions, please join our InfluxDB Community Slack or post them in our InfluxDB GitHub Repo or Community Site, and we will look into them.

InfluxDB University

Learn more about collecting data with Telegraf by taking the free InfluxDB University Data Collection with Telegraf course.

What's New in InfluxDB and Telegraf: Q2 2026 Product Updates

Ryan Nelson (InfluxData) — Wed, 01 Jul 2026 06:00:00 +0000

Here’s everything that shipped.

Telegraf Enterprise reaches general availability

Telegraf is the open source standard for collecting telemetry from infrastructure, applications, and devices. But what happens at scale? An enterprise running thousands of agents doesn’t have one collection problem; it has thousands of slightly different configs, no single view of agent health, and no safe way to roll out changes with confidence. Today, that usually means leaning on Ansible, Puppet, Chef, or some homegrown script nobody fully trusts. We built Telegraf Enterprise to solve that.

Telegraf Enterprise reached general availability on June 24, 2026, giving teams a centralized way to manage, monitor, and support tens of thousands of Telegraf agents. It combines Telegraf Controller, a console for fleet management, with official InfluxData support. Open source Telegraf doesn’t change—teams get the same lightweight agent and 400+ official plugins. What changes is the operational layer above it: one place to see every agent’s health, standardize configurations, and roll out fleet-wide changes with confidence.

For platform teams running telemetry across hundreds of environments, that visibility is the difference between reacting to problems and operating with control.

	Telegraf Controller (free)	Telegraf Enterprise
Managed agents	Up to 100	Enterprise scale (10,000s of agents)
Configurations	Up to 20	Unlimited
Audit logging	No	Yes
LDAP/OIDC	No	Yes
Support	Community	Official support for Controller and Telegraf

The free tier is enough to evaluate Telegraf Controller. Telegraf Enterprise removes the ceiling, adds the audit trail and identity integrations that production environments need, and upgrades in place with no disruption or re-platforming.

Download Telegraf Controller or contact us about Telegraf Enterprise to get started.

InfluxDB 3.9 and 3.10 close the gap before production

Running a database at the center of your stack takes more than speed. It takes operational control: who can access it, how quickly you can recover, how easily access scales with your team, and how reliably it performs under heavy load. InfluxDB 3.9 and InfluxDB 3.10, released June 17, 2026, deliver both. 3.9 strengthened day-to-day operations; 3.10 built on top of it, advancing the performance beta.

InfluxDB 3.9 focused on day-to-day operations, the kind that matters once a database is someone’s responsibility, not just a tool they query. 3.9 came with

CLI: new flags for headless automation and data validation
Database lifecycle: background resources like triggers now clean up properly on deletion
Access control: improved visibility across permissions and product identity for Core and Enterprise builds
Performance beta (opt-in, Enterprise): optimized single-series queries, smoother resource usage under heavy compaction or ingestion, wider and sparser schema support, and automatic distinct value caching to cut metadata query latency

InfluxDB 3.10 expanded the beta with enterprise features. Most teams aren’t held up by the database engine itself when they’re ready to go live. The basics hold them up: can we back this up, can we delete what we’re not supposed to keep, can we control who has access to what. 3.10 closes those gaps, offering:

End-to-end backup and restore
Row-level deletes by time range or tag predicate
Bulk import from Parquet files or directories
Multi-user auth and RBAC (preview): built-in Admin, Auditor, and Member roles with OAuth and OIDC support, no changes to existing token-based workflows

Outside the beta, every InfluxDB 3 Enterprise deployment gets cross-database plugin queries, a new / ready endpoint that checks object store connectivity before reporting healthy, and parallel compaction to keep query nodes current under heavy ingest.

On the performance side, 3.10 improves query latency for single-series lookups, last-value fetches, and hot-data access, with a reduction in average query latency over prior InfluxDB 3 releases on workloads that hit those paths. Metadata queries like SHOW TAG VALUES see the biggest jump, thanks to automatic distinct value caching. Results are workload-dependent, as always, but the direction is consistent: the trade-offs between scale, flexibility, and performance that real-time systems have to navigate are getting smaller, and the upgrade itself requires no migration and no architecture change.

Query with SQL, InfluxQL, or Flux in InfluxDB 3 Explorer

The Explorer UI started as a place to query data and ended up able to manage schema, move data in, stream it continuously, and speak whichever query language a team already runs.

You can now create, inspect, and delete tables directly in Explorer—no API calls, no CLI—with just the UI, plus a guided import from any v1, v2, or v3 instance and a Transform Data section for renaming, converting, filtering, and downsampling on ingest.

InfluxDB 3 Explorer also learned to keep data moving. MQTT, Kafka, and AMQP streams now wire directly into databases, two new Live Data plugins write continuously, and line protocol validates itself before a single row is written.

The headline addition in InfluxDB 3 Explorer 1.9 is an AI-assisted Flux-to-SQL converter that explains its own translations line by line, so migrating off Flux doesn’t mean rewriting every query by hand. Alongside it, InfluxQL became first-class in the Data Explorer, schema commands, per-tag charts, so teams that came up on InfluxDB 1.x or 2.x don’t have to leave the UI to use the commands they already know.

Teams keep the queries, data, and workflows they already rely on, and get there faster in InfluxDB 3.

A few things people have asked us

What’s the real difference between free Telegraf Controller and Telegraf Enterprise? Mostly limits and accountability. Free caps you at 100 agents and 20 configs with no audit trail. Enterprise removes the caps and adds the audit logging, LDAP/OIDC, and Enterprise Support that a real production fleet needs.

Do I have to migrate anything to get InfluxDB 3.10? No. It’s a seamless upgrade for existing InfluxDB 3 Enterprise and Cloud Dedicated customers. No migration tooling, no architecture change.

Can Explorer actually convert my Flux queries? Yes, the Flux-to-SQL converter is available in beta. Paste in a Flux query and get back equivalent SQL, plus a line-by-line explanation of how it got there.

Is InfluxQL fully supported in InfluxDB 3 now? As of Explorer 1.9, yes. It’s a first-class language in the Data Explorer alongside SQL, including the schema-exploration commands InfluxQL veterans rely on.

Looking ahead

Some of the most important work this quarter is still in progress. If you’re testing the performance beta or trying the Flux-to-SQL converter, we’d love to hear what’s working, what isn’t, and what you’d like to see next. That feedback plays a direct role in where we go from here.

What's New in InfluxDB 3 Explorer 1.9: Flux-to-SQL Conversion, InfluxQL Support, and More

Daniel Campbell (InfluxData) — Tue, 30 Jun 2026 07:30:00 +0000

InfluxDB 3 Explorer 1.9 makes it easier to work with your existing queries. Whether you’re migrating Flux queries to SQL or you’ve been writing in InfluxQL for years, this release helps bring your existing queries forward instead of starting from scratch.

For teams moving to v3 from earlier versions of InfluxDB, query migration is often one of the last major hurdles. Explorer 1.9 introduces an AI-assisted Flux-to-SQL converter to help automate that process, while also bringing InfluxQL directly into Explorer.

On top of that, this release adds two new live sample data simulators, an improved plugin log viewer, search across every list page, and query error history.

Convert Flux queries to SQL

InfluxDB 3 uses SQL and InfluxQL to query data, but many teams still have Flux queries powering dashboards and alerts they’d rather not rewrite by hand. The new Flux-to-SQL converter (beta) does that translation for you.

You’ll find it as a new tab in the Data Explorer, right next to SQL and InfluxQL. Paste in a Flux query, click Convert to SQL, and Explorer returns the equivalent InfluxDB 3 SQL in a side-by-side Flux and SQL layout. The conversion is powered by Kapa.ai, the same AI assistant behind the Ask AI helper on our documentation site.

Here’s a typical example. Take this Flux query that reads CPU idle and derives a “busy” percentage from it:

from(bucket: "instance_monitoring")
  |> range(start: -1h)
  |> filter(fn: (r) => r._measurement == "system_cpu")
  |> filter(fn: (r) => r._field == "idle")
  |> map(fn: (r) => ({r with busy: 100.0 - r._value}))

Click Convert, and you get back SQL:

SELECT
  time,
  100.0 - idle AS busy
FROM
  system_cpu
WHERE
  time >= now() - INTERVAL '1 hour'

It isn’t a black box, either. The tool explains each conversion, walking through the translation line by line. The range() call becomes the WHERE time clause, the _measurement filter becomes the FROM table, and the _field filter narrows things to the idle field, which in InfluxDB 3 is just a native column (no pivot() needed). The Flux map() that computes busy turns into a plain expression in the SELECT list, 100.0 - idle AS busy. The panel also flags a behavioral difference worth noting: Flux’s map() keeps every existing column, while the SQL selects only time and computed busy, so if you want the original idle alongside it, add it to the SELECT list or use SELECT *. When a database is selected, you can hit Run SQL Query and execute the converted query right there.

One note: the converter is beta and AI-generated, so its output can vary. Review the converted SQL before running your queries, and use the thumbs-up and thumbs-down buttons under the explanation to help improve future conversions.

InfluxQL comes to the Data Explorer

Many InfluxDB users have years of InfluxQL muscle memory, dashboards, and tooling built around it. In Explorer 1.9, InfluxQL is now a first-class query language. There’s an InfluxQL tab right beside SQL, you can run InfluxQL directly against your databases, save and load queries as InfluxQL, and view them in your query history alongside SQL. This matters because some things are simply more natural in InfluxQL. The schema-exploration commands are the clearest case: there’s no SQL equivalent for how InfluxQL asks a measurement which tag values it has. For example:

SHOW TAG VALUES FROM "bird_tracking" WITH KEY = "species"

That returns the distinct species in the table as a tidy key/value list. The same goes for SHOW MEASUREMENTS, SHOW TAG KEYS, and SHOW FIELD KEYS, along with time series idioms like GROUP BY time(5m) fill(previous) that don’t have a one-to-one SQL counterpart. If those are part of how you work, you no longer have to leave Explorer to use them.

InfluxQL visualizations, with per-tag series

InfluxQL results aren’t stuck in a table either. You can render them as line and bar charts, and Explorer automatically groups series by tag. Take this query:

SELECT mean("speed") FROM "bird_tracking"
WHERE time > now() - 1h
GROUP BY time(1m), "species" fill(none)

It produces one line per species, color-coded with a legend, exactly as you’d expect coming from earlier versions of InfluxDB. Group by a tag, get a series per tag value; switch between line and bar without rewriting anything.

Two new live sample data simulators

In 1.8, we added a Live Data tab to the Sample Data page, with Processing Engine plugins that continuously write data into a database on a schedule, so you have something moving to build dashboards and alerts against. 1.9 adds two more to the lineup, alongside the System Metrics Collector and US Weather Sampler.

The Bird Data Simulator generates synthetic bird telemetry: a persistent flock of named birds that move on each scheduled run with sinusoidal flight speed, drifting headings, and some temperature jitter. Each run writes to a bird_tracking measurement with species, name tags, and fields like speed, heading, latitude, and longitude. Because it’s naturally multi-series across many species, it pairs well with the per-tag InfluxQL charts above, and the only settings are volume controls, so it’s hard to misconfigure.

The Signal Generator is for when you want a clean, controllable signal instead of a realistic one. It produces composable waveforms (sine, square, triangle, sawtooth, noise, and spikes), and the default preset, a slow sine with light noise and occasional spikes, is immediately useful for testing alerts and anomaly detection. It fills gaps between runs so your data stays continuous, configurable, and reliant only on the Python standard library.

As with the other live plugins, you’ll need InfluxDB 3 Core or Enterprise with the Processing Engine enabled.

Quality-of-life improvements

A release isn’t only headline features. A few smaller changes in 1.9 take some daily friction out of Explorer.

A better plugin log viewer. Logs now open in a dedicated viewer with line numbers and color-coded output, a search box for finding a specific message, level filters for Info, Warn, and Error, and an Export button. Now you can filter straight to the errors, search for the exact message, and spot why a plugin misbehaved at a glance.

Search across every list page and a smarter database selector. Manage Databases, Tables, Tokens, the Plugin Dashboard, and server configuration now have search boxes, so you can find an item by typing a few characters. The database selector is also an autocomplete picker that works the same everywhere it appears, which saves time once you have more than a handful of databases.

Query error history. The query History panel now has an Errors tab next to your query history. Every failed query is captured with a timestamp, the query language, the database it ran against, the exact query text, and the full error message. So if a query fails, you can look back at precisely what went wrong instead of trying to reconstruct it.

The SQL editor also gets a Format button that cleans up and reflows a query for readability, handy for pasted one-liners. And the plugins page gets a Run now button, so you can trigger a plugin on demand instead of waiting for its next scheduled run, good for testing before you trust it to a schedule.

Try Explorer 1.9

If you’ve been putting off migrating Flux or you’ve been missing InfluxQL in the Explorer UI, this release closes both gaps, and the new simulators give you continuously flowing data to try it all against. If you skipped the last post, What’s New in InfluxDB 3 Explorer 1.8 covers streaming subscriptions, smarter sample data, line protocol validation, and retention controls.

To update InfluxDB 3 Explorer, pull the latest Docker image: docker pull influxdata/influxdb3-ui

To learn more, check out the InfluxDB 3 Explorer documentation and the 1.9 release notes.

InfluxData Blog - Developer

A Guide to Downsampling Time Series Data with InfluxDB 3

Why downsample time series data?

Choose Query-Time or Persisted Downsampling

Prerequisites

Generate Sample Telemetry with the Official Bird Simulator

Downsample at Query Time with SQL

Persist Downsampled Data with the Python Processing Engine

Why the Offset Matters

Inspect the Persisted Result

Sample Output

Validate the Reduction with SQL

Example Output

Downsampling best practices for production

Troubleshoot a scheduled downsampler

FAQs

What is downsampling?

How do I downsample data with InfluxDB 3 SQL?

When should I use the Python Processing Engine instead of SQL alone?

How do I prevent partial downsampling windows?

Does downsampling delete the original data?

What does record_count mean in the downsampled table?.

Can I calculate more than one aggregate per interval?

Does this approach work with InfluxDB 3 Cloud Serverless or Cloud Dedicated?

How much storage will downsampling save?

A Rust Client for InfluxDB 3

Why Rust, when Go and Python clients already exist?

Installation

Let Claude Write the Boilerplate

Configuring a client

Writing data

Points

Raw Line Protocol

Write Options

Which Write Endpoint?

High-Throughput Ingest

Querying data

Parameterized Queries

Working with Rows

Streaming Large Results

Reliability

Polars integration

Backfilling from Parquet Files

Loading CSV Exports

FAQ

What is influxdb3-client?

What Rust version does it require?

Does it work with InfluxDB Cloud Dedicated, Clustered, or Serverless, or only Core and Enterprise?

Does the client support InfluxDB 1.x or 2.x?

Why would I use this instead of the Go or Python client?

Is the Polars integration required?

Does it retry failed writes automatically?

Where do I report issues or request features?

Try it

Where Historians Fall Short for Physical AI

Where historians fall short for Physical AI

Retaining Operational History Versus a Live Model Feed

Compression Removes Relevant Signals for Model Training

The Cost of Fragmented Data

A modern time series architecture connects edge and cloud

Building a Context-Rich Training Dataset for Physical AI

Delivering Live Telemetry to AI at Inference

Built for the physical world

FAQ

What is Physical AI, and how does it differ from other forms of AI?

What's the difference between a data historian and a time series database?

Why can't traditional historians support real-time AI inference?

How does InfluxDB 3 help unify data across multiple industrial sites?

What’s New in InfluxDB 3.11: A Significant Performance Upgrade for Complex Time Series Workloads

Performance and flexibility for heavier, more complex workloads

Faster Reads for Single-Series Workloads

More Room for Wide, Sparse, and Changing Schemas

More Predictable Performance Under Load

New data management capabilities for Enterprise

InfluxDB 3 Explorer UI, now built in

Get started with InfluxDB 3.11

AI-Powered Spacecraft Operations with InfluxDB 3

Demo overview

From Telemetry Stream to Operator Signal

Detecting Anomalies as Data Arrives

What is `influxdb3-client?`