InfluxData Blog

What’s New in InfluxDB 3.10: Performance Beta Expanded with New Enterprise Features

Peter Barnett (InfluxData) — Wed, 17 Jun 2026 12:00:00 +0000

In our last release, we introduced a beta of performance updates designed for heavier, more complex time series workloads. InfluxDB 3.10 expands that beta to include enterprise features that give teams more control as they scale and manage larger workloads in InfluxDB 3.

This release adds end-to-end backup and restore, row-level deletes, bulk import from Parquet, user management, and an RBAC preview to the previous performance beta. It also includes cross-database plugin queries, a new readiness endpoint, and compaction improvements for InfluxDB 3 Enterprise. Together, these updates help teams evaluate the next phase of InfluxDB 3 performance and scale with more of the operational tooling they need to manage real workloads.

We’re inviting customers to test this next phase of InfluxDB 3 performance and scale, share feedback, and help shape the path to general availability.

Expanded capabilities for the performance beta

The performance improvements we previewed in InfluxDB 3.9 continue to mature in beta. These updates are designed for teams testing heavier time series workloads, including higher ingest, wider schemas, sparse data, and more demanding recent-data queries.

The beta remains opt-in and is not yet the default, so existing deployments continue running unaffected unless teams explicitly enable it with the --use-pacha-tree flag.

Once users opt in to the beta, InfluxDB 3.10 adds operational capabilities, so teams can do more than test raw performance. They can protect data, recover from known-good states, remove bad or unnecessary rows, and bring existing Parquet datasets into InfluxDB 3 for evaluation. That matters for teams working with real production patterns, where data rarely arrives perfectly clean and workloads rarely stay fixed.

The following capabilities are available only when using the performance beta, enabled with the --use-pacha-tree flag:

End-to-end backup and restore: You can now run full backups that capture cluster state and compacted data for easy rollbacks. Restores run asynchronously, allowing you to recover data into a fresh store for disaster recovery or roll a live cluster back to an earlier point in time. We’ll soon be adding incremental restores to give you even more control over your restore points.
Row-level deletes: Teams can now remove specific rows based on time ranges or tag predicates rather than dropping entire tables when data needs to be purged. The compactor applies these changes asynchronously in the background, allowing teams to clean up production data without interrupting operations.
Bulk import from Parquet: A new bulk-import function makes it easier to bring historical or external data into InfluxDB 3. Teams can point InfluxDB at a generic Parquet file or an entire directory, use simple column mappings, and ingest each file as an independent import job.

User authentication and RBAC preview

As time series workloads become more central to production systems, access control becomes increasingly important. The same database may support operators monitoring live systems, developers building applications, analysts exploring historical data, and automated services writing or transforming telemetry.

InfluxDB 3.10 Enterprise introduces a preview of multi-user authentication and role-based access control (RBAC). This feature is turned off by default for this release.

When enabled, operators can configure traditional username and password logins that issue JWTs, or opt for external identity management through OAuth and OIDC. 3.10 also introduces built-in roles, including Admin, Auditor, and Member, to enforce proper boundaries across your teams. Best of all, your existing token workflows will continue to work exactly as they do today without any breaking changes.

General updates and improvements

InfluxDB 3.10 also includes several capabilities that work across all deployments to streamline data pipelines and improve cluster management.

Cross-Database Plugin Queries

Time series data often moves through stages: raw telemetry, cleaned data, downsampled rollups, forecasts, anomaly scores, and application-ready views. Those stages may live in different databases, but teams still need to connect them without building unnecessary external pipelines.

In 3.10, Processing Engine plugins are no longer restricted to querying their own database. Now, a plugin can query any database residing on that node. This unlocks read-from-one, write-to-another data pipelines, such as reading raw telemetry from a staging database and writing compacted rollups or machine learning forecasts to a production database.

Readiness Endpoint

Production deployments need health checks that reflect whether a node can actually serve traffic, not just whether a process is running. InfluxDB 3.10 adds a new /ready endpoint. Instead of a basic uptime check, this endpoint verifies whether the node can successfully reach its underlying object store, giving operators a more reliable signal for traffic routing.

Improved Compaction

Under heavy ingest, compaction needs to keep pace with incoming writes so query nodes can access optimized data. When compaction stalls, the path from raw writes to efficient queries slows down. InfluxDB 3.10 introduces parallel compaction, ensuring that query nodes access fully compacted data more quickly and serve queries faster.

Get started with InfluxDB 3.10

InfluxDB 3.10 is available now. To get started, download the latest version or pull the newest Docker image for Core or Enterprise.

InfluxDB 3 Core remains free and open source under MIT and Apache 2 licenses, optimized for recent data and local workloads. InfluxDB 3 Enterprise adds long-range querying, clustering, advanced security, and full operational tooling for production deployments.

Check out the docs (Core, Enterprise), try the release in your environment, and share your feedback in Discord or the Community Slack. We want your feedback as the performance beta continues to mature.

Generate Synthetic Time Series Data in InfluxDB 3

Cole Bowden (InfluxData) — Fri, 12 Jun 2026 08:00:00 +0000

Getting InfluxDB 3 up and running is a pretty lightweight process with the installation script. Getting time series data into it is the next step, and for exploration, basic testing, or scenarios where you don’t have a stream of time series data ready to write, that can be a point of friction.

That hurdle is particularly high when you want to test the rest of the system around the data you’d be writing: dashboards, alerts, replication, network connectivity, edge devices, server sizing, or Processing Engine workflows—you don’t always have the ability to start writing production data into a freshly-installed database, or you may not have that data yet.

Two new InfluxDB 3 plugins help with exactly that: the Bird Tracking Simulator and the Signal Generator. Both are scheduled plugins that generate data directly to InfluxDB 3, making it easy to start writing realistic sample data with a single trigger. The Bird Tracking Simulator creates synthetic bird telemetry, while the Signal Generator creates configurable waveform data for sensor-like or metric-like use cases.

Why generate sample data this way?

A lot of InfluxDB workflows are easier to understand once data is actively moving through the system:a dashboard is easier to build when the line and the most recent datapoint keep changing, an alert is easier to validate when values cross a threshold, edge replication is easier to test when writes are arriving continuously, and a small server or single-board computer is easier to evaluate when you can watch how it behaves under a steady stream of points.

These plugins are meant to make that first step simple. Create a database, create a trigger, and InfluxDB 3 starts generating data on a schedule. From there, you can query it, visualize it, replicate it, downsample it, or use it as input for other Processing Engine plugins.

Bird Tracking Simulator

The Bird Tracking Simulator generates a stream of synthetic bird telemetry. On its first run, it creates a persistent flock of named birds, assigns each bird a variety of tags, such as species, name, and range, and stores the flock in the Processing Engine cache. Each scheduled execution of the plugin advances the flock by updating a number of measurements, including speed, heading, latitude, and longitude, with the birds going on random walks within a predefined range for each species.

The shape of the data is useful for a few reasons. It has multiple entities, tags, and geospatial fields. It changes over time in a way that is easy to inspect visually. That makes it a good fit for testing dashboards, map panels, edge replication, and basic query patterns that group or filter by tags.

The plugin writes to the bird_tracking measurement. Its configuration is also intentionally small, specified with simple trigger arguments: bird_count controls how many persistent birds are tracked, and points_per_bird controls how many movement points each bird emits per scheduled run. The defaults are 25 birds and 1 point per bird. The number of data points the plugin generates is a simple product of these two options and the trigger specification for how often the plugin runs.

The plugin requires Faker, so install that first:

influxdb3 install package Faker

Then create a database and a scheduled trigger:

influxdb3 create database sample_data

influxdb3 create trigger \
  --database sample_data \
  --path "gh:influxdata/bird_data_simulator/bird_data_simulator.py" \
  --trigger-spec "every:10s" \
  --trigger-arguments bird_count=10,points_per_bird=10 \
  bird_tracking_demo

After the trigger has run a few times, query the generated data:

influxdb3 query \
  --database sample_data \
  "SELECT * FROM bird_tracking ORDER BY time DESC LIMIT 5"

For a denser stream, increase the flock size, increase the points per bird, or adjust the trigger interval. That gives you a simple way to create a steady stream of entity-oriented time series data. You can use it to populate dashboards, test writes across a network, or quickly confirm that a new InfluxDB 3 setup is receiving, storing, and querying data as expected.

Signal Generator

The Signal Generator achieves many of the same things, but by generating numeric signals rather than named entities. The default preset produces a signal centered around 30, with a slow sine trend, Gaussian noise, and occasional spikes. It uses only the Python standard library, supports configurable measurement names, field names, tags, and point resolution, and can compose multiple waveform types together. Supported waveform types include sine, square, triangle, sawtooth, noise, and spike.

That makes it useful for testing dashboards, threshold checks, alerting behavior, anomaly detection, and any workflow that requires a predictable yet non-static stream of numeric values. A line with trend, noise, and the occasional spike gives you something closer to the patterns you usually care about when working with time series data.

The simplest version uses the default preset:

influxdb3 create database signals

influxdb3 create trigger \
  --database signals \
  --path "gh:influxdata/signal_generator/signal_generator.py" \
  --trigger-spec "every:10s" \
  signal_basic

Once the trigger has run, query the latest generated values:

influxdb3 query \
  --database signals \
  "SELECT time, value FROM signal ORDER BY time DESC LIMIT 10"

You can also aggregate the generated signal over time:

influxdb3 query \
  --database signals \
  "SELECT
     time_bucket(time, INTERVAL '1 minute') AS minute,
     AVG(value) AS avg_value,
     MIN(value) AS min_value,
     MAX(value) AS max_value
   FROM signal
   WHERE time > now() - INTERVAL '1 hour'
   GROUP BY minute
   ORDER BY minute DESC"

For custom waveforms, the plugin can be configured with JSON arguments through InfluxDB 3 Explorer or the Processing Engine API. That lets you define signals for different measurements, fields, and tags, or stack waveforms together to create the shape you want.

For example, you might create one signal that looks like a temperature sensor, another that behaves like CPU utilization, and another that emits occasional spikes to test an alerting path. Because each trigger can have its own configuration, you can build out a small set of synthetic streams that exercise different parts of your system.

Lightweight data generation for InfluxDB 3

The Bird Tracking Simulator and Signal Generator are small plugins, but they solve a useful problem: they make it easy to get fresh time series data flowing through InfluxDB 3 with very little setup, allowing you to test your deployment and ensure data is flowing to and from every system downstream of your InfluxDB instance.

Use the Bird Tracking Simulator when you want moving, entity-oriented telemetry with tags and location fields. Use the Signal Generator when you want numeric signal data for dashboards, alerts, thresholds, and processing workflows.

Check out the plugins in the InfluxDB 3 plugin repository, try them on the hardware you already have, and use them as a quick way to exercise InfluxDB 3, the Processing Engine, and the systems connected to them.

Satellite Telemetry, ITAR, and Data Residency: Building Architecture for Speed and Control

Allyson Boate (InfluxData) — Thu, 11 Jun 2026 08:00:00 +0000

Satellite mission operators depend on telemetry to understand spacecraft health, ground system performance, and mission status in real-time. Operation signals help teams identify risks, investigate anomalies, and keep operations moving.

When a spacecraft enters safe mode or signal strength drops during a contact window, teams need trusted telemetry immediately. But mission data moves quickly across operational systems, and every handoff makes it harder to control.

How can teams keep telemetry fast, useful, and available while maintaining control over sensitive mission data?

Why ITAR and data residency matter for telemetry

For satellite operators, sensitive mission data raises two practical questions: who can access the data, and where can it go? ITAR and data residency requirements bring those questions into the monitoring conversation.

ITAR, or International Traffic in Arms Regulations, controls how certain defense-related products, services, and technical data can be shared. In practice, these rules help prevent sensitive information from moving to unauthorized people, systems, or environments.

Technical data does not always stay attached to hardware, but can show how spacecraft systems operate, perform, fail, or respond under real conditions. Battery temperature, solar panel output, signal strength, contact window performance, and subsystem fault codes help teams monitor spacecraft health; those readings may also reveal performance limits or operational patterns that require closer review.

Legal and compliance teams determine which telemetry falls under ITAR or other export-control requirements. Classification alone does not protect the data. Engineering and infrastructure teams need systems that enforce those decisions as telemetry moves through daily operations.

Data Movement Creates the Control Challenge

Data residency adds the next layer. Telemetry may originate from spacecraft, ground systems, payload systems, and mission infrastructure, then move through ground stations, dashboards, cloud tools, analytics workflows, vendor systems, and long-term archives. Each stop creates another place where mission data may live, get copied, or become accessible.

When teams cannot trace readings across those systems, compliance reviews take longer and ownership becomes harder to prove. Security teams may struggle to confirm who accessed the data, where copies exist, and which system serves as the source of truth. Mission teams may also lose time reconstructing event timelines across systems.

The architecture needs to answer the practical questions behind the compliance review: where mission data lives, who can access it, how long teams retain it, and how it moves across systems.

What data sprawl costs mission teams

Data silos and sprawl create the most risk when mission teams need to act quickly. During an anomaly, engineers need a clear sequence of events: what changed, when it changed, and which systems contributed.

A ground station contact window can expose the cost. A satellite reports rising battery temperature, irregular power draw, and a sudden safe mode event. To identify the cause, engineers need to trace battery temperature, power draw, command history, subsystem fault codes, and communications data from the minutes leading up to the event.

When each data source lives in a different tool, the response slows. One team checks a dashboard, another pulls logs from cloud storage, and another reviews an exported file from an analytics workflow. Engineers spend critical time reconciling records instead of isolating the issue. Those disconnected workflows create operational and governance costs at the same time. Mission teams lose speed during anomaly response. Compliance and security teams lose visibility into where sensitive telemetry lives, who can access it, and which copies exist.

How InfluxDB 3 supports controlled telemetry monitoring

With InfluxDB 3, satellite teams can bring high-volume operational signals from spacecraft, ground systems, and infrastructure into a shared time series architecture. When mission information lives across disconnected dashboards, logs, and exports, engineers have to piece together telemetry from multiple systems. With a shared time series architecture, engineers can analyze time-organized signals in one place, compare readings against historical baselines, and respond faster when anomalies occur.

How the Architecture Works

A controlled data architecture starts with ingestion. Telemetry from spacecraft, ground systems, payload systems, and mission infrastructure can flow through Telegraf agents, MQTT pipelines, or other approved collection paths into InfluxDB 3 as time-stamped data. Tags add operational context, such as spacecraft ID, subsystem, ground station, or signal source.

Once telemetry enters the database, teams can query across systems without moving data into separate files or one-off tools. Engineers can compare current signal strength against previous contact windows, review power draw before a safe mode event, and correlate reaction wheel performance with temperature changes over time.

Dashboards and alerts can use the same telemetry record. Operators can monitor live spacecraft health, trigger alerts when values drift from expected ranges, and investigate anomalies with historical context. Retention and downsampling extend the workflow over time, helping teams keep high-resolution telemetry where detail matters and preserve long-term trends as data ages.

Deployment Flexibility for Sensitive Data

For satellite operators working with sensitive data, flexibility matters. Without deployment control, organizations risk signals moving outside approved environments, granting access to the wrong users or systems, and creating copies that complicate internal reviews.

InfluxDB 3 Core gives teams a self-managed option for real-time telemetry ingest and recent-data queries in edge, on-premises, or private cloud environments. Self-managed deployment helps teams keep time series workloads closer to mission operations, ground systems, or other reviewed infrastructure.

InfluxDB 3 Enterprise builds on that foundation for production workloads. High availability helps maintain access to mission data during critical operations. Read replicas can support dashboards, investigations, and analytics traffic without putting extra pressure on ingest workloads. Multi-node deployment options help teams separate ingest, query, and compaction as data volumes grow. While InfluxDB 3 does not determine whether telemetry falls under ITAR or make an organization compliant by default, it aligns telemetry workflows with internal requirements for storage, access, retention, and deployment.

Eutelsat OneWeb: Satellite Telemetry at Scale

Eutelsat OneWeb puts this deployment flexibility into play. The company operates a hybrid constellation with more than 600 LEO satellites, each producing more than 50,000 values. Across the constellation, the operations team processes more than 1 million data points per second.

At this scale, they needed a platform that could handle high-volume time series data, support real-time monitoring, and help engineers analyze spacecraft and ground-segment behavior in one place.

The company built a telemetry stack with InfluxDB as the centralized time series engine, Telegraf agents across the ground segment, and Grafana for dashboards, alerting, and cross-system correlation. InfluxDB supports more than 15 million unique series.

This architecture gives the team a unified way to explore spacecraft and ground-segment data side by side. Engineers can monitor satellite health, correlate time series data across systems, trigger alerts from InfluxDB queries, and replay events for root-cause analysis. With that shared operational timeline, the team can analyze mission behavior across spacecraft and ground-segment systems.

Read the full case study to check out how Eutelsat OneWeb uses InfluxDB to manage satellite telemetry.

The bottom line

Satellite telemetry needs to move fast, but sensitive mission data also needs control. When telemetry spreads across disconnected systems, teams lose time during anomaly response and confidence during compliance review. A unified time series architecture helps satellite operators keep telemetry queryable, comparable, and governed across live operations and historical analysis.

To get started, explore InfluxDB 3 Core OSS or InfluxDB 3 Enterprise to see how time series architecture can support real-time mission visibility, historical analysis, and controlled data workflows.

Building a Predictive Maintenance Plugin with the InfluxDB 3 Processing Engine

Charles Mahler (InfluxData) — Tue, 09 Jun 2026 08:00:00 +0000

Predictive maintenance is one of the most compelling use cases for time series data. Instead of waiting for equipment to fail or servicing it on a fixed calendar regardless of condition, you watch the live sensor data and act when it indicates that a failure is coming. That “watch the data and act” loop is exactly what the InfluxDB 3 Processing Engine was built for.

In this tutorial, we’ll build a working predictive maintenance plugin from scratch. We’ll install InfluxDB 3 Core, load a well-known public dataset of jet engine sensor data, write a Python plugin that runs inside the database to estimate each engine’s Remaining Useful Life (RUL), and have it raise maintenance alerts automatically. By the end, you’ll have an end-to-end system that you can adapt to pumps, motors, HVAC units, CNC machines, or any other instrumented asset.

What we’re building

Here’s the architecture at a glance:

Sensor data lands in InfluxDB 3 Core. We’ll use NASA’s C-MAPSS turbofan engine degradation dataset, replayed into a sensors table as if it were arriving live from a fleet of engines.
A scheduled plugin runs every minute. It queries the most recent sensor readings per engine, computes a health/degradation score, and converts that into an estimated Remaining Useful Life.
The plugin writes its conclusions back into the database. RUL estimates go into a rul_estimates table, and when an engine crosses a danger threshold, the plugin writes a row into a maintenance_alerts table and logs a warning.

The key idea is that the analysis logic lives embedded in the database. There’s no separate service to deploy, scale, or keep in sync. When data arrives, the engine acts on it.

Prerequisites

Before starting, make sure you have:

A Linux or macOS machine (Windows works too via the installer or Docker; commands below assume a Unix-like shell)
Command-line access
Python 3 installed locally
The train_FD001.txt file from the C-MAPSS dataset

That’s it. InfluxDB 3 Core itself is a single binary and brings its own bundled Python for plugins.

Install InfluxDB 3 Core

The quickest path is the official install script, which always pulls the latest release:

curl -O https://www.influxdata.com/d/install_influxdb3.sh \
  && sh install_influxdb3.sh core

When the script finishes, confirm it worked:

influxdb3 --version

If the influxdb3 command isn’t found, the installer’s output tells you what to do—usually it’s a matter of sourcing your shell config (for example source ~/.bashrc or source ~/.zshrc) so the new binary is on your PATH.

Docker

If you’d rather containerize, the Processing Engine is enabled by default in the Docker image (the plugin directory defaults to /plugins):

docker run -it -p 8181:8181 --name influxdb3-core \
  --volume ~/.influxdb3_data:/var/lib/influxdb3 \
  --volume ~/.influxdb3_plugins:/plugins \
  influxdb:3-core influxdb3 serve \
  --node-id my_host \
  --object-store file \
  --data-dir /var/lib/influxdb3 \
  --plugin-dir /plugins

For the rest of this tutorial we’ll assume the local binary install. The commands translate directly to Docker by prefixing docker exec -it influxdb3-core.

Start InfluxDB with the Processing Engine enabled

The Processing Engine activates only when you tell InfluxDB where your plugins live, using the --plugin-dir flag.

First create a directory to hold plugins, then start the server:

mkdir -p ~/influxdb3/plugins

influxdb3 serve \
  --node-id host01 \
  --object-store file \
  --data-dir ~/.influxdb3 \
  --plugin-dir ~/influxdb3/plugins

A few notes on these flags:

--node-id is a unique name for this server instance. It forms part of the storage path.
--object-store file keeps everything on a local disk under
--data-dir. In production you’d point this at S3 or another object store; InfluxDB 3 uses a “diskless” architecture where object storage is the source of truth.
--plugin-dir is the directory the engine scans for plugin files. This is the switch that turns the Processing Engine on.

Leave this server running in its own terminal. Open a second terminal for the remaining commands.

It’s worth noting that the influxdb3 binary depends on an adjacent python/ directory that ships alongside it. If you extracted from a tarball manually, keep the binary and that python/ folder in the same parent directory and add the parent to your PATH, don’t move the binary out on its own, or plugins won’t run.

Create an admin token

InfluxDB 3 Core uses token authentication. Several operations require an admin token. Create one with the following command:

influxdb3 create token --admin

This prints a token string once. Copy it somewhere safe; you can’t recover it later (you’d have to regenerate). For convenience in this session, export it:

export INFLUXDB3_AUTH_TOKEN="paste-your-token-here"

The CLI automatically picks up INFLUXDB3_AUTH_TOKEN, so you won’t have to pass --token on every command.

Create a database

Create a database to hold our data:

influxdb3 create database engine_fleet

Verify it exists:

influxdb3 show databases

You should see engine_fleet in the list.

Load the dataset into InfluxDB

The C-MAPSS file is a flat, headerless, space-separated table. We need to turn each row into a time series point. There’s one wrinkle worth thinking through: the data has a time_cycles counter per engine, not real timestamps. To make this behave like a live stream, we’ll synthesize timestamps by mapping each engine cycle to one second of wall-clock time, anchored to “now minus the engine’s lifetime.” That way recent cycles look recent, which is what a scheduled “look at the last N minutes” plugin expects.

Here’s a small loader script. It uses the InfluxDB 3 Python client to write line protocol in batches. First install the client into your local Python (this is separate from the engine’s bundled Python), using uv or venv for package management if desired::

pip install influxdb3-python pandas

Save the following as load_cmapss.py, adjusting DATA_FILE and TOKEN as needed:

# load_cmapss.py
import time
from datetime import datetime, timedelta, timezone

import pandas as pd
from influxdb_client_3 import InfluxDBClient3, Point

# ---- Configuration ----
DATA_FILE = "train_FD001.txt"
HOST = "http://localhost:8181"
DATABASE = "engine_fleet"
TOKEN = "paste-your-admin-token"   # or read from env

# ---- Column names (NASA C-MAPSS layout) ----
index_cols = ["unit_number", "time_cycles"]
setting_cols = ["setting_1", "setting_2", "setting_3"]
sensor_cols = [f"s_{i}" for i in range(1, 22)]
col_names = index_cols + setting_cols + sensor_cols

# ---- Read the space-separated file ----
df = pd.read_csv(DATA_FILE, sep=r"\s+", header=None, names=col_names)
df = df.astype({"unit_number": int, "time_cycles": int})

print(f"Loaded {len(df)} rows across {df['unit_number'].nunique()} engines")

# ---- Synthesize timestamps: 1 cycle == 1 second, anchored so the
#      last cycle of each engine lands at 'now'. ----
now = datetime.now(timezone.utc)
client = InfluxDBClient3(host=HOST, database=DATABASE, token=TOKEN)

points = []
BATCH = 5000

# Per-engine max cycle so we can anchor each engine's final cycle to "now"
max_cycle = df.groupby("unit_number")["time_cycles"].transform("max")
df["ts"] = [
    now - timedelta(seconds=int(mc - tc))
    for mc, tc in zip(max_cycle, df["time_cycles"])
]

for row in df.itertuples(index=False):
    p = (
        Point("sensors")
        .tag("unit_number", str(row.unit_number))
        .field("time_cycles", int(row.time_cycles))
    )
    for c in setting_cols + sensor_cols:
        p = p.field(c, float(getattr(row, c)))
    p = p.time(row.ts)
    points.append(p)

    if len(points) >= BATCH:
        client.write(points)
        points = []

if points:
    client.write(points)

client.close()
print("Done writing sensor data.")

Run it:

python load_cmapss.py

A few design choices worth calling out:

unit_number is a tag, everything else is a field. Tags are indexed and are how you separate one engine’s series from another. Sensor values and the cycle counter are fields.
We anchor each engine’s final cycle to “now.” This means every engine in the fleet looks like it just reached end-of-life, which is convenient for demonstrating alerts. In a real deployment your data already has real timestamps and you’d skip all of this.
Batching matters. Writing 20,000+ points one at a time is slow; batches of a few thousand keep the loader quick.

Confirm the data landed:

influxdb3 query --database engine_fleet \
  "SELECT COUNT(*) FROM sensors"
And take a peek at one engine's recent readings:
influxdb3 query --database engine_fleet \
  "SELECT time, unit_number, time_cycles, s_2, s_4, s_11 \
   FROM sensors WHERE unit_number = '1' \
   ORDER BY time DESC LIMIT 5"

An overview of the plugin model

Before writing code, let’s get the mental model straight.

A plugin is a Python file (or a directory with an __init__.py for multi-file plugins) placed in your plugin directory. It defines a function whose signature matches the trigger type:

Data-write plugin: def process_writes(influxdb3_local, table_batches, args=None):</pre>
Scheduled plugin: def process_scheduled_call(influxdb3_local, call_time, args=None):</pre>
HTTP-request plugin: def process_request(influxdb3_local, query_parameters, request_headers, request_body, args=None):</pre>

A trigger is the database resource that connects an event to a plugin. You create it with influxdb3 create trigger, specifying a trigger spec that defines when the plugin runs.

Whatever the type, every plugin receives influxdb3_local which is the shared API object that’s your gateway to the database. The methods we’ll use:

influxdb3_local.query(sql) - run a SQL query and get results back as a list of dictionaries.
influxdb3_local.write(line) - write a point back into the database, built with the LineBuilder helper.
influxdb3_local.info(msg)/ .warn(msg) / .error(msg) - log to stdout and the system.processing_engine_logs table.
The engine also offers an in-memory cache for keeping state between runs (useful for things like tracking a rolling baseline), though we’ll keep our first version stateless.

LineBuilder is the recommended way to construct a point inside a plugin:

line = LineBuilder("my_table")
line.tag("device", "pump_7")
line.float64_field("value", 42.0)
line.int64_field("count", 3)
influxdb3_local.write(line)

Plugins receive trigger arguments as a Dict[str, str] in args, which is how we’ll pass tunable thresholds without editing code.

Predictive maintenance plugin logic

We need to turn raw sensor readings into a Remaining Useful Life estimate. A full production system might run a trained LSTM or gradient-boosted model, but a tutorial plugin should be transparent and dependency-light, so we’ll use a degradation-index approach that captures the real idea behind RUL prediction without a black box:

Pick the sensors that carry degradation signals. In FD001, several sensors drift steadily as the high-pressure compressor wears. Sensors s_2, s_3, s_4, s_8, s_11, s_13, and s_15 trend upward over an engine’s life; s_7, s_12, s_20, and s_21 trend downward. (Some sensors in FD001 are flat and carry no information—we ignore those.)
Normalize each chosen sensor against the healthy-baseline range so they’re comparable, flipping the downward-trending ones so “more degraded” always means “higher.”
Average them into a single health index between roughly 0 (factory-fresh) and 1 (failure imminent).
Map the index to an RUL estimate. Using the dataset convention that degradation becomes meaningfully predictable in roughly the final 125 cycles, we estimate RUL ≈ 125 × (1 − health_index).
Alert when the estimated RUL drops below a configurable threshold.

This is intentionally simple and explainable. The plugin structure is identical whether the scoring function is ten lines of arithmetic or a 50-megabyte neural network, you’d just swap the body of compute_health_index.

To normalize, the plugin needs each sensor’s healthy and degraded reference values. Rather than hard-code magic numbers, we’ll derive them once at the top of each run from the fleet itself with the early-life readings approximate “healthy” and the latest readings approximate “degraded.”

Creating the plugin

Create the plugin file directly in your plugin directory. Save this as ~/influxdb3/plugins/predictive_maintenance.py.

# predictive_maintenance.py
#
# Scheduled plugin: estimates Remaining Useful Life (RUL) for each engine
# from the most recent sensor readings, writes the estimates back into the
# database, and raises alerts when RUL drops below a threshold.

# Sensors that rise as the engine degrades
RISING = ["s_2", "s_3", "s_4", "s_8", "s_11", "s_13", "s_15"]
# Sensors that fall as the engine degrades
FALLING = ["s_7", "s_12", "s_20", "s_21"]

# Convention from the C-MAPSS literature: degradation becomes meaningfully
# predictable in roughly the final 125 cycles.
MAX_PREDICTABLE_RUL = 125.0

def _safe_float(value, default=0.0):
    try:
        return float(value)
    except (TypeError, ValueError):
        return default

def compute_baselines(influxdb3_local):
    """Derive healthy and degraded reference values for each sensor.

    Healthy  ~ average of the earliest cycles across the fleet.
    Degraded ~ average of the latest cycles across the fleet.
    """
    sensors = RISING + FALLING
    avg_cols = ", ".join([f"AVG({s}) AS {s}" for s in sensors])

    healthy_rows = influxdb3_local.query(
        f"SELECT {avg_cols} FROM sensors WHERE time_cycles = 15"
    )
    degraded_rows = influxdb3_local.query(
        f"SELECT {avg_cols} FROM sensors WHERE time_cycles = 175"
    )

    if not healthy_rows or not degraded_rows:
        return None

    healthy = healthy_rows[0]
    degraded = degraded_rows[0]

    baselines = {}
    for s in sensors:
        lo = _safe_float(healthy.get(s))
        hi = _safe_float(degraded.get(s))
        baselines[s] = (lo, hi)
    return baselines

def normalize(value, lo, hi):
    """Scale a reading to 0..1 between the healthy (lo) and degraded (hi)
    references. Clamps to the [0, 1] range."""
    if hi == lo:
        return 0.0
    frac = (value - lo) / (hi - lo)
    return max(0.0, min(1.0, frac))

def compute_health_index(reading, baselines):
    """Combine the signal-bearing sensors into a single 0..1 degradation
    index. 0 = healthy, 1 = failure imminent."""
    scores = []

    for s in RISING:
        lo, hi = baselines[s]
        scores.append(normalize(_safe_float(reading.get(s)), lo, hi))

    for s in FALLING:
        lo, hi = baselines[s]
        # Falling sensors: degraded value is lower, so invert the scale.
        scores.append(1.0 - normalize(_safe_float(reading.get(s)), hi, lo))

    if not scores:
        return 0.0
    return sum(scores) / len(scores)

def process_scheduled_call(influxdb3_local, call_time, args=None):
    # --- Read tunables from trigger arguments ---
    args = args or {}
    rul_threshold = float(args.get("rul_threshold", "30"))
    lookback = args.get("lookback", "10m")

    influxdb3_local.info(
        f"Predictive maintenance run starting. "
        f"rul_threshold={rul_threshold}, lookback={lookback}"
    )

    # --- Build per-sensor baselines from the fleet ---
    baselines = compute_baselines(influxdb3_local)
    if baselines is None:
        influxdb3_local.warn("Not enough data to compute baselines; skipping run.")
        return

    # --- Get the most recent reading per engine ---
    sensor_select = ", ".join(RISING + FALLING)
    latest = influxdb3_local.query(
        f"""
        SELECT unit_number, time_cycles, {sensor_select}
        FROM sensors
        WHERE time >= now() - INTERVAL '{lookback}'
        ORDER BY time DESC
        """
    )

    if not latest:
        influxdb3_local.warn("No recent sensor data in lookback window.")
        return

    # Keep only the newest row per engine (results are time-desc ordered).
    seen = set()
    newest_per_engine = []
    for row in latest:
        unit = row.get("unit_number")
        if unit not in seen:
            seen.add(unit)
            newest_per_engine.append(row)

    alerts = 0
    for row in newest_per_engine:
        unit = str(row.get("unit_number"))
        cycles = int(_safe_float(row.get("time_cycles")))

        health = compute_health_index(row, baselines)
        est_rul = round(MAX_PREDICTABLE_RUL * (1.0 - health), 1)

        # --- Write the RUL estimate ---
        est = LineBuilder("rul_estimates")
        est.tag("unit_number", unit)
        est.float64_field("health_index", round(health, 4))
        est.float64_field("estimated_rul", est_rul)
        est.int64_field("time_cycles", cycles)
        influxdb3_local.write(est)

        # --- Raise an alert if the engine is in the danger zone ---
        if est_rul = rul_threshold:
            alerts += 1
            severity = "critical" if est_rul = rul_threshold / 2 else "warning"

            alert = LineBuilder("maintenance_alerts")
            alert.tag("unit_number", unit)
            alert.tag("severity", severity)
            alert.float64_field("estimated_rul", est_rul)
            alert.float64_field("health_index", round(health, 4))
            influxdb3_local.write(alert)

            influxdb3_local.warn(
                f"[{severity.upper()}] Engine {unit}: estimated RUL "
                f"{est_rul} cycles (health index {round(health, 2)}). "
                f"Schedule maintenance."
            )

    influxdb3_local.info(
        f"Run complete. Scored {len(newest_per_engine)} engines, "
        f"raised {alerts} alert(s)."
    )

Let’s walk through the important parts.

Baselines from the data help us avoid any magic numbers. - compute_baselines asks the database for the average sensor values during early life (cycles ≤ 15, “healthy”) and late life (cycles ≥ 175, “degraded”). This adapts automatically to your fleet and means you don’t have to know the absolute scale of s_4 in advance.
A single, explainable health index. compute_health_index normalizes each signal-bearing sensor onto a 0–1 scale and averages them. Rising and falling sensors are both oriented so that 1 always means “more degraded.” This is the piece you’d replace with a trained model in production — the surrounding plumbing stays identical.
Newest reading per engine. The query pulls everything in the lookback window ordered newest-first, then we keep the first row we see for each unit_number. Because of how we loaded the data (each engine’s last cycle anchored to “now”), the most recent rows are the most degraded.
Writing conclusions back. Every engine gets a row in rul_estimates. Engines past the threshold also get a row in maintenance_alerts, tagged with a severity derived from how deep into the danger zone they are, plus a logged warning you’ll see in the server terminal.
Configurable via trigger arguments. rul_threshold and lookback come from args, so you can retune behavior by recreating the trigger.

Creating the trigger

Now connect the plugin to a schedule. We’ll run it every minute, with a 30-cycle RUL alert threshold and a 10-minute lookback window:

influxdb3 create trigger \
  --trigger-spec "every:1m" \
  --path "predictive_maintenance.py" \
  --trigger-arguments "rul_threshold=30,lookback=10m" \
  --database engine_fleet \
  pdm_scheduler

Breaking that down:

--trigger-spec "every:1m" runs the plugin once a minute. You could also use cron: for calendar schedules, for example cron:0 0 8 * * * for 8am daily (the format includes seconds).
--path "predictive_maintenance.py" is the filename relative to your plugin directory. (For a multi-file plugin you’d point this at the directory containing __init__.py instead.)
--trigger-arguments passes our tunables as key=value pairs.
pdm_scheduler is the trigger’s name.

The trigger is enabled by default and starts running on the next interval boundary.

Testing out the plugin

Within a minute, the plugin fires. Check the server terminal and you’ll see the info and warn log lines. Now query what it produced.

The latest RUL estimates, most-degraded first:

influxdb3 query --database engine_fleet \
  "SELECT unit_number, estimated_rul, health_index, time_cycles \
   FROM rul_estimates \
   ORDER BY time DESC, estimated_rul ASC LIMIT 15"

The maintenance alerts:

influxdb3 query --database engine_fleet \
  "SELECT time, unit_number, severity, estimated_rul, health_index \
   FROM maintenance_alerts \
   ORDER BY time DESC LIMIT 20"

If you want to confirm the plugin is registered and see its file details:

influxdb3 show plugins

And the engines flagged critical right now:

influxdb3 query --database engine_fleet \
  "SELECT unit_number, estimated_rul FROM maintenance_alerts \
   WHERE severity = 'critical' ORDER BY estimated_rul ASC"

You should see a spread of RUL estimates across the fleet, with the most-degraded engines surfacing as warnings or criticals.

Inspecting logs and iterating

Plugin logs go both to the server’s stdout and to a system table, which is handy for debugging without scrolling the terminal:

influxdb3 query --database engine_fleet \
  "SELECT * FROM system.processing_engine_logs ORDER BY time DESC LIMIT 20"

When you change the plugin code, you don’t need to recreate the trigger. Edit the file and push the update, preserving the trigger’s configuration and history:

influxdb3 update trigger \
  --database engine_fleet \
  --trigger-name pdm_scheduler \
  --path "predictive_maintenance.py"

For local development you can also develop a plugin on your own machine and upload it with --upload when creating or updating a trigger, which copies the file to the server for you (this requires an admin token). And if you want to dry-run a scheduled plugin without waiting for the interval, there’s influxdb3 test schedule_plugin.

To pause the system without deleting anything:

influxdb3 disable trigger --database engine_fleet pdm_scheduler
# ...and later...
influxdb3 enable trigger --database engine_fleet pdm_scheduler

Error Handling

By default, plugin errors are logged and the trigger keeps going. For a critical pipeline you might prefer automatic retries or auto-disable. Set this when creating the trigger with --error-behavior retry or --error-behavior disable (the default is log).

What to build next

You now have a complete, self-contained predictive maintenance loop running inside InfluxDB 3 Core. Some natural extensions:

Swap in a real model. Replace compute_health_index with a trained regressor or classifier. Install the library with influxdb3 install package, load your serialized model at the top of the plugin, and predict per engine. The trigger, the writes, and the alerts don’t change.
Add a notifier. Have the alert branch call an external service like Slack, PagerDuty, email directly from Python. InfluxData also publishes an official notifier plugin you can compose with.
Use the engine’s cache for stateful detection. Track a rolling baseline or a per-engine trend slope across runs instead of recomputing fleet baselines each time, using the in-memory cache to persist state between executions.
Lower the latency. Move from a scheduled trigger to a data-write trigger if you need to react the moment a reading crosses a line.
Browse the official plugin library. InfluxData maintains a public repository of plugins (anomaly detection via MAD, threshold/deadman checks, Prophet forecasting, downsampling, and more) that you can reference directly in a trigger with the gh: prefix, or copy and adapt.

The broader point is the pattern: with the InfluxDB 3 Processing Engine, the intelligence lives in the database, next to the data, reacting as the data moves. For time-series-heavy domains like industrial IoT and predictive maintenance, that proximity is exactly what you want.

Anomaly Detection and Forecasting That Learns From Every Write in InfluxDB

Cole Bowden, Ryan Nelson (InfluxData) — Thu, 04 Jun 2026 08:00:00 +0000

For many operational time series workloads, machine learning can’t operate in the historical way, where data is compiled once and models are trained offline. Sensor readings, infrastructure metrics, application telemetry, energy data, industrial measurements, and financial ticks all share a basic property: the next datapoint is more useful when the system can respond to it immediately (or at least close to immediately). When a model learns in the same flow that ingests data and reacts to incoming data as it’s written, things like anomaly detection, short-horizon forecasting, and adaptive thresholding all become a lot more useful.

Enter three new River-based plugins for InfluxDB 3:

These plugins are built for the InfluxDB 3 Processing Engine and leverage River, a Python library for online machine learning. If you’re unfamiliar with it, the Processing Engine is an embedded Python VM that runs inside InfluxDB 3 and can execute plugin code on writes, schedules, or HTTP requests; it also provides an in-memory cache for stateful applications. For write-triggered plugins, InfluxDB 3 can send batches of data to a plugin as data is flushed through the write-ahead log. River, meanwhile, is designed for models that learn from streaming data incrementally, including anomaly detection, drift detection, and time series forecasting.

That combination makes InfluxDB 3 and River a perfect match. These plugins bring small, per-series, constantly-updating models directly into the write path, then write the resulting profiles, anomalies, and forecasts back into InfluxDB tables where they can be queried like any other time series data or combined with other triggers and plugins to kick off informed actions. Better yet, they do this all within InfluxDB, eliminating the need for extra infrastructure, servers, and data pipelines to fuel your ML models. In this blog, we’re going to talk about all three new River plugins for InfluxDB, and how they can not only simplify your ML stack, but lead to faster insights through online modeling.

River Anomaly Detector: multiple ways to detect problematic data

Let’s start with the River Anomaly Detector. At a high level, the plugin monitors numeric fields and writes anomaly rows to the table _anomalies.{source_table}. It supports rolling Z-score detection, seasonal detection, and adaptive window (ADWIN)-based drift detection. Each unique combination of table, tags, and field has its own detector state, and models are updated incrementally as new observations arrive.

The rolling detector tracks an exponentially weighted mean and variance, then flags values that exceed the learned range by a configurable number of standard deviations. The seasonal detector maintains separate time-based buckets, either 24 hour-of-day buckets or 168 hour-of-week buckets, and it compares new values against the bucket that matches the current timestamp. The ADWIN detector watches for changes in the statistical properties of the stream, which is useful when the issue is a behavior shift rather than a single spike.

Detectors learn from every observation, and you can choose to enable one, two, or all three detector modes, but only the detectors active in the current mode can vote on whether a point is anomalous. This allows you to train the various forms of anomaly detection, then modify your trigger once enough data has been provided to the model. This way, a stream can accumulate enough seasonal history before the seasonal detector is allowed to participate in decisions, and ADWIN can keep learning even when the current mode is using a simpler rolling Z-score path. You don’t even need to specify which detector to use; run the plugin with a minimal trigger such as the following:

influxdb3 install package river

influxdb3 create trigger \
 --database mydb \
 --plugin-filename gh:influxdata/river_anomaly_detector/river_anomaly_detector.py \
 --trigger-spec "all_tables" \
 anomaly_detector

With that trigger in place, the plugin starts monitoring numeric fields in all incoming tables. The default behavior is to “auto-tune” and read recommendations from the River Auto Profiling plugin, which we’ll dive into more in the next section. A typical query against the output might look like this:

SELECT
 time,
 host,
 field_name,
 original_value,
 detector_mode,
 rolling_mean,
 rolling_std,
 rolling_deviation,
 rolling_threshold,
 seasonal_bucket,
 drift_detected
FROM "_anomalies.cpu"
ORDER BY time DESC
LIMIT 20;

That output is deliberately detailed: you get the original value, the active detector mode, rolling statistics, seasonal statistics when available, and ADWIN drift information. The plugin only writes rows where a datapoint is determined to be an anomaly, so the anomaly table is an event stream rather than a full copy of the source data.

For a stable metric, the detector may run with a lower Z-score threshold because small deviations are meaningful. For a noisy metric, it may use a higher threshold to avoid producing noise. For a metric with a strong weekly pattern, seasonal buckets can separate “expected at 2 p.m. on Monday” from “expected in general.” For a metric that is drifting, ADWIN can participate so the detector can respond to changes in the stream rather than treating every shift as a one-off outlier.

You can also make the mode explicit. For example, if you only care about a specific table and you know it has strong daily or weekly seasonality on a couple fields you want to monitor, you can specify this and force the plugin to only use seasonal detection:

influxdb3 create trigger \
 --database mydb \
 --plugin-filename gh:influxdata/river_anomaly_detector/river_anomaly_detector.py \
 --trigger-spec "table:cpu" \
 --trigger-arguments \
   'include_fields=temperature humidity' \
   'rolling_std_threshold=3.0' \
   'enable_seasonal=true' \
 anomaly_detector_cpu

The detector can encode understanding in the database itself, close to the data, while still leaving room for explicit configuration when you know exactly what you want. Whether you want adaptive detection, rolling Z-scores, seasonal detection, or some combination of the three, the River Anomaly Detector plugin can make it happen, and it’s truly as simple as defining the tables and fields you want it to operate on.

River Auto-Profiler: the control plane for per-series tuning

The Auto-Profiler is the least flashy of the three plugins, but it is the one that makes the anomaly detector more practical at scale.

A static threshold is easy to understand and easy to deploy. It is also usually wrong somewhere. A metric that barely moves, a metric with high variance, a metric with a weekly pattern, and a metric undergoing a slow drift should not all use the same anomaly detection settings. You can tune each field by hand, but that does not scale well when your schema grows or when the behavior of a series changes over time.

The Auto-Profiler addresses that by incrementally profiling each numeric series and writing recommendations to _meta.series_profiles. It tracks exponentially weighted mean and variance, skewness, kurtosis, write interval, and seasonal variance buckets. After a short calibration phase, it writes profile snapshots that include a pattern label, recommended detector mode, threshold, fading factors, seasonality strength, trend strength, and maturity flags.

Creating the trigger is intentionally simple:

influxdb3 create trigger \
 --database mydb \
 --plugin-filename gh:influxdata/river_auto_profiler/river_auto_profiler.py \
 --trigger-spec "all_tables" \
 auto_profiler

Then you can inspect the current profile state:

SELECT
 time,
 source_table,
 host,
 field_name,
 observations,
 pattern_label,
 recommended_detector_mode,
 recommended_threshold,
 recommended_fading_factor,
 seasonality_strength,
 trend_strength,
 profile_mature,
 seasonality_ready
FROM "_meta.series_profiles"
ORDER BY time DESC
LIMIT 20;

The classifier is intentionally transparent. It labels streams as stable, noisy, trending, seasonal, or bursty and maps those labels to detector modes such as zscore_low, zscore_high, zscore_adaptive, zscore_conservative seasonal, or zscore_conservative adwin. Seasonality detection uses hourly or weekly variance buckets, and trend detection compares fast and slow exponentially weighted means.

That transparency is useful. If a profile says a series is seasonal, you can look at the seasonality_strength and seasonal_buckets_filled fields. If it says a series is trending, you can inspect trend_strength. If the profile is not mature yet, downstream consumers can fall back to safer defaults.

The Auto-Profiler also tunes thresholds using observed exceedance behavior. It tracks how often observations fall outside mean ± threshold × std and adjusts the threshold toward an approximate target anomaly rate, with bounds to avoid unbounded sensitivity changes. That does not make anomaly detection “automatic” in the magical sense. It makes it adaptive in the operational sense: the system can use what it has learned about each series to pick a more appropriate starting point.

The most important integration is with the anomaly detector. With both plugins deployed, the profiler writes per-series recommendations, and the anomaly detector consumes those recommendations to adapt to your data, weed out anomalies, and minimize noise.

River Forecaster: short-horizon forecasts from the write stream

The River Forecaster takes the same online-learning pattern and applies it to forecasting. The plugin uses River’s SNARIMAX model, an online ARIMA-style model, to learn from incoming values and periodically write multi-step forecasts to _forecasts.{source_table}. Like the anomaly detector, it keeps a separate model per table/tag/field series. Unlike the anomaly detector, it requires explicit table selection through include_tables, which is a necessary guardrail for forecast cardinality.

A trigger for the forecasting plugin might look like this:

influxdb3 create trigger \
 --database mydb \
 --plugin-filename gh:influxdata/river_forecaster/river_forecaster.py \
 --trigger-spec "all_tables" \
 --trigger-arguments \
   "include_tables=system_cpu system_memory" \
   "include_fields=idle used available" \
   "max_series=100" \
   "default_horizon=24" \
   "log_forecasts=true" \
 forecaster

By default, the model waits for a warm-up period before producing forecasts. The forecast horizon is also derived from the stream. The plugin tracks each model’s write interval and uses it to choose how many future steps are needed to cover a target forecast window, which defaults to one hour. If a series is written every 10 seconds, the forecast horizon can be much longer than a series written every five minutes, because the time window is the same, but the step size is different.

You can query forecasts like this:

SELECT
 time,
 host,
 field_name,
 horizon_step,
 forecast_value,
 horizon_total,
 observations
FROM "_forecasts.system_cpu"
ORDER BY time DESC
LIMIT 12;

Each forecast row receives a future timestamp based on the last observed timestamp plus horizon_step * write_interval_seconds. The output includes the forecasted value, the step number, total horizon length, and the number of observations the model has learned from.

The forecaster also self-throttles per model. It produces a forecast, stores those predictions in memory, and then compares them step by step against incoming actuals. A new forecast is produced once the previous forecast horizon has been consumed, so evaluation covers the full horizon rather than a partial subset.

That makes the plugin useful for near-term operational questions. For the example above (forecasting CPU and system memory utilization), these questions might be:

Is memory usage expected to cross a threshold in the next hour?
Is a sensor trending toward a range that usually precedes maintenance?
Is the current CPU-idle forecast consistent with what the anomaly detector is seeing?

These are not the only forecasting questions you might ask of time series data, but they are the kind that fit well in a write-triggered architecture.

Using the River plugins with InfluxDB

With the simplicity of InfluxDB 3’s embedded Processing Engine, getting started with notoriously difficult or complicated ML tasks is now simpler, faster, and easier than ever. For all three of these River ML plugins, you can view the code and README files within the InfluxDB 3 plugin repository, with full documentation for configuration and recommended use. Installing them is as simple as defining and starting the triggers within the processing engine.

Make sure you’re intentional about which tables and fields you monitor. You should think about cold starts, profile maturity, and whether a given field has enough regularity for short-horizon forecasting. These questions exist whenever you’re deploying ML techniques on data—this isn’t magic.

Once you have the plugins up and running, everything should work seamlessly as described above, adapting and learning from the data written to your tables. All three plugins’ outputs remain in InfluxDB. Profiles are written to _meta.series_profiles. Any detected anomalies are written to _anomalies.{source_table}. Forecasts are written to _forecasts.{source_table}.

That means the operational burden is small, and you can query profiles, anomalies, forecasts, and raw data with SQL. You can visualize your River ML-generated data in dashboards alongside the raw and processed data you’ve written into InfluxDB, join different datasets together, and inspect behavior, anomalies, and forecasts without needing to involve any other services or platforms. You don’t need additional hardware or pipelines or self-written plugins to extract your time series data into an offline system for ML. It may just be the easiest way to leverage your time series data for machine learning out there. By embedding these plugins within InfluxDB, your training workflows and ML insights can now live closer to the raw data than ever before.

6 Signs Your Historian Renewal Should Be a Modernization Conversation

Ryan Nelson (InfluxData) — Mon, 01 Jun 2026 08:00:00 +0000

Renewal notices don’t arrive with a subject line that says “modernization conversation enclosed.” They show up as a line item in procurement, usually with a larger number than the previous year. Most teams sign and move on.

The ones that pause tend to find the renewal moment is a useful forcing function, not to rip out the historian, but to ask whether the current architecture can support what the business needs over the next three years.

If any of the following sounds familiar, that audit is worth running before you sign.

Sign 1: Your renewal quote is higher, and so is your tag count

The math used to work. When the historian was first deployed, per-tag pricing was predictable. You knew the count, you knew the cost, and the line item made sense against the operational value it delivered. However, that equation breaks down as instrumentation expands.

For example, AVEVA PI customers are seeing renewal pressure even as their tag counts increase. Some organizations have seen AVEVA pricing increase 20-40% over the last 18 months. That creates the wrong incentive: collect less data, sample less often, or pay more for the visibility the business now needs.

There’s a compounding factor that often goes unexamined. Deprecated tags, from decommissioned equipment, retired sensors, or replaced instrumentation, still count toward your license. The pricing model doesn’t distinguish between a tag that’s actively collecting at 1Hz and one that’s been dark for two years. In industries where equipment turns over regularly, paying full price for data you no longer collect is an inevitability. The tag footprint grows in both directions: new assets add tags at the front, old ones don’t shed them at the back.

If your procurement team is asking why the historian line item keeps growing while your OT team can’t fully instrument what it needs to, the commercial model has already stopped working for you.

Sign 2: Your data science team is still waiting for that export

This appears consistently across industrial organizations. Analytics and AI initiatives get funded, data scientists are hired, and then they spend the first few months writing tickets to the OT team asking for historian exports.

PI Vision and PI DataLink weren’t built for Python, pandas, or Databricks.
Getting data out requires proprietary connectors, manual exports, or PI Web API integrations that take weeks to stand up.
By the time the data reaches the ML pipeline, it’s stale, downsampled, or stripped of the context it needs to be useful.
The data science team that was supposed to be building predictive maintenance models is still, months later, doing data plumbing.

There’s a structural issue behind the export problem. Historians were built to store industrial tags, usually SCADA or PLC-process information, mapped to an ISA-95 hierarchy. What they weren’t designed to do is store metadata and context alongside raw industrial signals. That gap matters more as analytics mature.

Enriching SCADA data with MES data about production shifts, ERP data about batches and stock levels, or equipment metadata for grouping by manufacturing type requires a platform that treats context as a first-class citizen alongside telemetry. Without it, even a well-delivered data export produces a one-dimensional analysis. You see what happened, but you don’t understand why.

If “how do we give the analytics team access to OT data” is still an open question, you’re looking at a historian problem.

Sign 3: A new workload just got bounced back to you

Someone in the business asked you to support something the historian wasn’t built for:

Cell-level monitoring for a new BESS installation at 1Hz, when your historian’s default polling interval is 5-15 minutes.
Vibration analysis on rotating equipment, where sub-second resolution is required, and tag economics become punishing fast.
A new greenfield facility where the capital plan assumes modern, cloud-connected data infrastructure.
A real-time anomaly detection model that needs data before the dashboard refresh cycle catches it.

When your answer has to be “the historian can’t do that at that frequency” or “it can, but here’s what the additional tags will cost,” the conversation has changed. The workloads the business needs have outpaced what the platform was sized for.

The throughput problem has a storage dimension too, and it’s the one that tends to catch teams off-guard. Historians weren’t built for indefinite storage of high-volume, high-frequency data. Industry 4.0 use cases, including predictive maintenance models, asset warranty tracking, and long-range efficiency analysis, need data stored over years, not rolling windows. When you try to do that in a historian, storage costs compound quickly, and data accessibility often degrades. The business case for those use cases depends on querying three years of sensor data quickly. A historian scoped for operational visibility doesn’t make that easy.

Sign 4: Every plant is an island

Your historian keeps the plant running. It doesn’t know the fleet exists.

Cross-site benchmarking requires custom middleware that someone has to build, maintain, and eventually explain to their replacement.
Fleet-level analysis comparing performance across sites means extracting and normalizing data from multiple historian instances with inconsistent tag naming.
Centralized reporting for leadership involves someone in OT running manual aggregation every Monday.
Each new site gets the same plant-centric architecture, compounding the cross-site problem with every expansion.

The plant-island problem goes deeper than data access. Each site typically operates by its own data standard, with tag naming conventions, unit definitions, and hierarchy structures that made sense locally but weren’t designed for comparison. Cross-plant analysis requires a standardization layer built and maintained on top of the historian, and that layer tends to be fragile, undocumented, and owned by whoever happened to build it.

There’s also an architectural concern that digital transformation teams are raising with increasing frequency: reaching back into plant networks to pull data from individual historian instances creates bandwidth and security risk. The better pattern is a single, standardized interface at the enterprise layer, one that aggregates and normalizes across sites without requiring anyone to access operational technology networks to run a comparison report.

Sign 5: The platform is a closed system, and that’s becoming a problem

Historians accumulate dependencies as much as they accumulate data. The proprietary architecture that made them reliable for single-site operational visibility also makes them difficult to extend, integrate, or evolve.

Integrations are built through proprietary SDKs and connectors. When a vendor discontinues one, the integration breaks.
The platform’s data model isn’t designed to connect with open standards like SQL, JDBC, or ODBC without significant middleware investment.
Every new capability, whether a new visualization layer, analytics integration, or edge deployment pattern, requires either a vendor-supplied solution or a custom workaround.
Legacy .NET dependencies constrain where and how the platform can be deployed, and the team managing it today is working from a roadmap they don’t control.

This is where vendor lock-in stops being an abstract concern and becomes an operational one. Every renewal locks in the architecture for another cycle. Teams that don’t own their data layer, can’t control their integration strategy, and can’t switch tools without rebuilding from scratch are paying for a constraint, not just a platform.

Open standards, SQL, JDBC, ODBC, and common client libraries, exist precisely to avoid this. They let teams retain skills, use the right tool for the right job, and avoid designing in a vendor dependency that becomes painful at exactly the moment of renewal.

Sign 6: “Historian limitations” shows up in every initiative’s risk log

This is the one that tends to crystallize things for digital transformation and operations leaders. At some point, the pattern becomes visible:

BESS monitoring is blocked by polling intervals.
The ML pipeline is blocked by proprietary data access.
Cloud migration is complicated by the on-prem historian footprint.
Edge data collection for remote assets requires custom workarounds.
Cross-site analytics is deferred indefinitely, pending a middleware project that never gets resourced.

When the historian appears in the constraints column on enough project charters, teams stop treating it as a given and start treating it as something to engineer around. That shift in framing is usually the start of a different conversation.

What to do about it, before signing a contract

None of this necessarily means replacing the historian. Most industrial teams that modernize their data infrastructure augment their deployment rather than pursuing an immediate rip-and-replace.

The pattern that has worked for organizations like Terega and SP Energy Networks is to deploy InfluxDB alongside AVEVA PI. In those deployments, the historian handles legacy SCADA historization, GxP data, and established PI Vision workflows, while InfluxDB takes on high-frequency BESS monitoring, predictive maintenance pipelines, new greenfield sites, and cross-site fleet analytics.

Compute-based pricing means unlimited tags, with no per-sensor cost penalty.
Native SQL, 14 client libraries, and direct Grafana, Power BI, and Python integration with no proprietary SDK.
InfluxDB 3 Core runs at the edge; Enterprise or Cloud serves as the central hub, with one SQL interface across both.

For organizations facing a significant renewal, planning a new facility, or actively evaluating a full exit from the historian architecture, the path is a complete replacement. This includes InfluxDB for time series storage, and Litmus Edge or Highbyte for industrial connectivity and asset modeling.

Terega, the French gas network operator, deployed InfluxDB alongside their historian when they were heading toward seven-figure annual OSI PI costs. They now collect 20x more data at 50% lower cost. SP Energy Networks became the first UK utility to receive Ofgem approval for a cloud-hosted historian, running on InfluxDB. That decision has since opened the door for other regulated UK operators to evaluate the same path.

The renewal notice is a useful moment. Use it to ask whether the current architecture can carry what the business needs from it next, and what it would take to find out.

[Get InfluxDB free] InfluxDB 3 Core is open source and available now. Deploy at the edge in minutes. No per-tag pricing. Native SQL. Direct Grafana and Power BI integration.

InfluxDB 3 MCP Server v1.3.0: AI Access to Time Series Data

Jason Stirnaman (InfluxData) — Thu, 28 May 2026 02:00:00 +0000

A more reliable agent that learns your schema, queries your data, and investigates alerts - that’s what’s possible with this release of our MCP server v1.3.0.

TL;DR

This release enhances the InfluxDB 3 MCP server—which already allows AI agents like Claude and ChatGPT to read from and write to your InfluxDB 3 instance using natural language—with key dependability improvements, including protocol compliance tests, integration tests, and a properly scoped npm package.

What it is: an MCP server that exposes InfluxDB 3 tools, including query, write, schema discovery, database management, and token management, to any MCP-compatible client.
What changed in 1.3.0: test coverage, CI, the updated MCP SDK (1.27.1), @influxdata/influxdb3-client 1.4.0, a Node 20.11+ baseline, and safer error responses.
Install: npx -y @influxdata/influxdb3-mcp-server. No clone, no build.
See it work: we ran an agent investigation against the influxdb3-ref-bess reference architecture with prompts for schema discovery, current state, forcing a thermal runaway alert, and pivoting back to readings.
Where to get it: npm · Docker · GitHub · CHANGELOG

What is the InfluxDB 3 MCP server?

The Model Context Protocol is an open standard for connecting AI agents to external tools and data. Our MCP server is the official InfluxData implementation: it runs locally over stdio, accepts a connection from your MCP client (Claude Desktop, Claude Code, OpenAI Codex, Cursor, and others), and exposes InfluxDB 3 as a set of tools the agent can call on your behalf.

It works across all InfluxDB 3 editions—Core, Enterprise, Cloud Dedicated, Cloud Serverless, and Clustered—with tools adapted to each product. For example, admin token management is only available on Core and Enterprise; bucket retention is a Cloud Serverless concern.

For background and the original tool tour, see our previous posts: Introducing the InfluxDB 3 MCP server and Building with the InfluxDB 3 MCP server & Claude.

What’s new in v1.3.0?

This release makes the MCP server safer and more dependable:

Scoped npm package. The official server is now @influxdata/influxdb3-mcp-server (the unscoped influxdb-mcp-server on npm is an unrelated community project); always use the scoped name.
Protocol-compliance test suite. Verifies server startup, the MCP handshake, and tool/resource/prompt registration.
Integration tests against Core and Cloud Serverless. A first set covering health_check, list_databases, and execute_query.
__Server-level errors now set isError__: true, matching handler-level responses. MCP clients see failures as failures, not as empty success responses.
Plain-text error responses (HTTP 500) from Core now pass through to the MCP client with their original message, instead of being replaced by a generic “Internal Server Error.”
MCP SDK 1.12 → 1.27.1 and @influxdata/influxdb3-client 1.1 → 1.4.0.
Node 20.11 minimum: Node 18 reached end of life.

How do I install the MCP Server for InfluxDB 3 Core?

If you haven’t already installed Core and created an admin token, follow the Set up Core guide (you’ll be running within 5 minutes).

The following example uses npx, which is the easiest way to get started.

Add the server to your MCP client config. For Claude Desktop, edit claude_desktop_config.json:

{
  "mcpServers": {
    "influxdb": {
      "command": "npx",
      "args": ["-y", "@influxdata/influxdb3-mcp-server"],
      "env": {
        "INFLUX_DB_INSTANCE_URL": "http://localhost:8181/",
        "INFLUX_DB_TOKEN": "YOUR_ADMIN_TOKEN",
        "INFLUX_DB_PRODUCT_TYPE": "core"
      }
    }
  }
}

Restart Claude Desktop. The first launch downloads the package; subsequent launches are instant.
Sanity-check. Open a new chat and ask: “Use the InfluxDB tools to list my databases.” Claude should call the list_databases tool and return whatever’s on your instance.

Other MCP Clients

The README includes specific config-file snippets for other MCP clients.

Prefer Docker? The v1.3.0 image is on Docker Hub at influxdata/influxdb3-mcp-server. Our January walkthrough covers the Docker-based setup in detail.

How do I install the MCP Server for InfluxDB 3 Enterprise?

Enterprise uses the same configuration shape, just replace the environment variable values:

{
  "mcpServers": {
    "influxdb": {
      "command": "npx",
      "args": ["-y", "@influxdata/influxdb3-mcp-server"],
      "env": {
        "INFLUX_DB_INSTANCE_URL": "https://your-enterprise-host/",
        "INFLUX_DB_TOKEN": "YOUR_ADMIN_TOKEN",
        "INFLUX_DB_PRODUCT_TYPE": "enterprise"
      }
    }
  }
}

Enterprise adds licensed multi-node and read/write replica features, but to the MCP client, the tools look the same as Core. The Enterprise install guide covers licensing and provisioning.

Cloud Variants

Cloud Serverless uses the same three-variable shape, just swap the URL and set INFLUX_DB_PRODUCT_TYPE=cloud-serverless. Cloud Dedicated and Clustered are slightly different: Cloud Dedicated takes a cluster ID instead of a host URL, and both support an optional separate management token. See the exact recipe for each in the MCP server README.

Try it against a real running system

Run MCP against live data in one of our reference architecture demos to simulate a real environment. The ref arch demos run on InfluxDB 3 Enterprise by default.

influxdb3-ref-bess is our reference architecture for Battery Energy Storage Systems on InfluxDB 3: a simulator writing 768 cells across 4 packs at ~2,000 points per second, in-database Python plugins performing thermal-runaway detection and daily SoH rollups, and a control-room UI. make demo brings the whole thing up in about two minutes.

Point your MCP server’s INFLUX_DB_INSTANCE_URL and INFLUX_DB_TOKEN at the ref-arch instance, and set INFLUX_DB_PRODUCT_TYPE=enterprise. An agent now has a real plant to investigate. Here’s a session we ran in Claude Code.

Orient.

“I have InfluxDB 3 running locally with a BESS reference simulator writing data into it. List the databases on this instance, then, for the bess database, show me which measurements exist and the schema of each.”

The agent chose the tools and made seven calls: list_databases, then get_measurements and get_measurement_schema once per table. It returned this summary: cell_readings (per-cell voltage and temperature), pack_readings (pack-level current, SoC, SoH), inverter_readings (site power), and alerts (an event stream written by an in-database plugin when a cell crosses a threshold).

Current state of the plant.

“Show me the current state of each pack: the most recent current_a, SoC, and SoH per pack_id from pack_readings.”

pack     current_a   SoC      SoH       as of
pack-0   -80.0       53.0%    98.1%     14:09:36
pack-1   -80.0       61.8%    97.9%     14:09:36
pack-2   -80.0       63.8%    98.1%     14:09:36
pack-3   -80.0       60.8%    98.0%     14:09:36

The agent used DISTINCT ON (pack_id) ... ORDER BY pack_id, time DESC, the DataFusion/Postgres idiom for “latest row per group,” which is typically cheaper than the more portable ROW_NUMBER() window-function pattern. It picked the SQL from the schema it discovered in prompt 1. The agent also flagged a simulator bug that we hadn’t asked about: all four packs were reporting the same current. Real BESS sites rarely dispatch evenly due to SoC balancing, thermal derating, and inverter routing.

Investigate alerts.

“Any alerts in the last 15 minutes in the alerts table? If so, find the most recent alert’s pack_id and timestamp, then show me the cell_readings from that pack within a one-minute window around the alert time.”

The result: zero alerts. The agent ran one query for the 15-minute window, ran a second query to confirm the table had no rows, and then declined to invent any. It didn’t fabricate rows or an alert just because we’d asked for one. The MCP server’s error handling keeps errors distinct from success, and makes empty results easy to distinguish from silence.

Force the alert condition.

“Force a hot cell in bess so that the thermal-runaway trigger fires.”

The agent read the plugin source to learn the threshold (temperature_c > 70), then wrote one synthetic line-protocol row for pack-0/module-0/cell-0 at 85 °C using write_line_protocol. The Processing Engine’s WAL trigger fired in-process on that write and emitted a row into alerts. No restart or orchestration is required because plugins run inside InfluxDB 3.

Now run the original investigation.

“Show me the cell readings around that alert.”

The agent’s first attempt asked for ±1 minute and received 1,542 rows, which it then narrowed to the hot cell’s timeline:

time            voltage   temperature_c
14:12:41.617    3.643     22.08
14:12:57.071    3.646     22.20
14:13:07.557    3.650     85.00   ← injected, fires alert
14:13:12.529    3.646     22.00
14:13:27.989    3.646     21.90

The temperature spike alone triggered the alert, but the agent also flagged what we should expect for a real thermal event: “in a real cell, an 85 °C excursion would correlate with voltage and current anomalies.”

Five prompts, no handwritten SQL: discover the schema, read the current state, search alert events, write a single line of synthetic data to fire the trigger, and tie the resulting alert back to the underlying readings.

A Runnable Reference Architecture for Industrial IoT on InfluxDB 3

Jason Stirnaman (InfluxData) — Fri, 22 May 2026 08:00:00 +0000

Industrial teams keep telling us the same thing: the data is there, but the stack to act on it isn’t. PLCs, CNCs, SCADA systems, vibration sensors, and quality stations all generate high-frequency telemetry that gets stranded in proprietary historians or stitched together with point integrations nobody wants to own. By the time anyone looks at it, the moment to act has passed.

We built InfluxDB 3 to be the system of record for that data—at the edge, in the cloud, or both—and we keep getting the same follow-up question: what does a real, working IIoT stack on InfluxDB 3 look like?

So we shipped one. Today, we’re walking through the InfluxDB 3 IIoT Reference Architecture, an open-source, runnable blueprint for factory-floor monitoring that you can stand up locally in about two minutes with docker compose. We’ll also cover when and how to bring in the new OPC UA Plugin, our Processing Engine plugin for connecting InfluxDB 3 directly to PLCs and SCADA systems.

What is the InfluxDB 3 IIoT reference architecture?

The IIoT reference architecture is one of a portfolio of open source reference architectures we publish on GitHub for InfluxDB 3 Enterprise. Each one targets a specific vertical: IIoT, Battery Energy Storage Systems (BESS), network telemetry, EV charging, fleet telematics, data center, and oil & gas SCADA are all on the way.

Two audiences use these repos:

Developers and architects evaluating InfluxDB 3 Enterprise for a specific vertical who want to see a real stack, not slideware, before they commit.
AI coding agents that need grounded, working examples to reference when a user asks them to build something like this with InfluxDB 3. (Yes, we wrote this with you in mind.)

The IIoT repo simulates an automotive-style assembly plant: 1 plant × 3 lines × 8 stations = 24 machines, generating roughly 300 points per second. Everything runs locally. Clone the repo, run make up, and you get a working factory-floor monitoring stack, including a live andon board UI, in your browser at http://localhost:8080.

What’s in the stack

The whole thing is Python-first and stays deliberately small. docker-compose.yml brings up six services:

token-bootstrap – generates and persists tokens for first-boot
influxdb3 — InfluxDB 3 Enterprise, the system of record
init – bootstraps the database, caches, and Processing Engine triggers
simulator – a Python simulator generating realistic IIoT telemetry (machine state, part events, quality signals, downtime patterns)
ui – a FastAPI + HTMX + uPlot dashboard that renders an andon board, OEE breakdowns, and live machine state
scenarios – scripted fault scenarios you can replay (unplanned_downtime_cascade, tool_wear_quality_drift)

You’ll notice what’s not here: there’s no Telegraf, no MQTT broker, no Kepware, no Node-RED, no Grafana. That’s intentional. This reference architecture is designed to showcase what InfluxDB 3 Enterprise can do natively, without bolt-on services. In production, you’ll almost certainly add some of those (more on that below).

The features it’s actually showing you

If you’ve used earlier versions of InfluxDB, the headline change in 3 Enterprise is that the database is no longer just a place where data sits. Three capabilities do most of the work in the IIoT reference architecture:

1. The Processing Engine – Python plugins running inside the database

The Processing Engine is an embedded Python virtual machine that runs inside an InfluxDB 3 server. It executes Python code in response to triggers and database events with zero-copy access to data and direct access to system caches. It does all of this without relying on external services or middleware. Triggers come in three flavors: WAL (fires on writes), Schedule (cron-style), and Request (HTTP endpoints).

The IIoT repo ships four plugins, intentionally chosen to cover all three patterns:

That last one is the pattern that surprises most teams: the andon board’s /api/v3/engine/andon_board endpoint is the database. There is no Flask server, no Node service, no Lambda. The UI talks straight to InfluxDB 3, and the Processing Engine returns a fully shaped JSON payload. The UI also renders a served by Processing Engine: N ms badge so you can see the round-trip live.

2. Last Value Cache – single-digit-millisecond current state

The plant-state banner needs to read the current state of all 24 machines on every tick. With Last Value Cache, that’s a 24-row read in single-digit milliseconds, with no scanning, no aggregation, and no trade-offs against retention. This is the pattern you reach for any time you need current value, right now: SoC for a battery, alarm state for a substation, the live tag value for a machine.

3. Distinct Value Cache – fast cardinality on high-cardinality tags

The simulator generates roughly 700,000 part events per day, each tagged with a unique part_id. Asking “how many distinct parts have we produced today?” against that volume would normally be the kind of query you avoid running during shift change. With Distinct Value Cache, it returns in a few milliseconds.

Together, these three primitives, Processing Engine, Last Value Cache, and Distinct Value Cache, replace a surprising amount of what teams used to build out as separate microservices, message queues, and read-replica caches.

When to bring in OPC UA: the Processing Engine plugin

The IIoT reference architecture uses a Python simulator as its data source, so you don’t need real industrial hardware to run it. In production, your data is on the wire from PLCs, CNCs, and SCADA systems, and the lingua franca of that wire is OPC UA.

That’s where the OPC UA Plugin comes in. It’s a Processing Engine plugin (so it runs inside InfluxDB 3, same as the andon board endpoint above) that connects to an OPC UA server, polls node values on a schedule, and writes them in as time series. It requires InfluxDB 3.8.2 or later and works with both Core and Enterprise.

A few characteristics worth knowing:

Polling-based, not subscription-based. The plugin reads current values on each scheduled trigger.
Two operating modes. Explicit node listing for precise control over a small number of nodes; browse mode for auto-discovering devices and variables across large deployments. Browse mode maps the OPC UA Object hierarchy directly to InfluxDB tags.
Auto type detection. OPC UA VariantType maps cleanly into InfluxDB field types (Boolean → bool, Int* family → int, UInt* family → uint, Float/Double → float).
Namespace URI support. Use stable namespace URIs (nsu=urn:vendor:s7;…) instead of numeric indexes that may change on server restart.
Quality filtering by good, uncertain, or bad status codes.
Persistent connection between polling intervals, with automatic reconnection.
TLS security supports Basic128Rsa15, Basic256, Basic256Sha256, Aes128Sha256RsaOaep, and Aes256Sha256RsaPss, with Sign or SignAndEncrypt modes.

Setup is two commands plus a trigger:

# 1. Start InfluxDB 3 with the Processing Engine enabled
influxdb3 serve \
  --node-id node0 \
  --object-store file \
  --data-dir ~/.influxdb3 \
  --plugin-dir ~/.plugins

# 2. Install the async OPC UA client library
influxdb3 install package asyncua

# 3. Create a polling trigger (browse mode for auto-discovery)
influxdb3 create trigger \
  --database mydb \
  --plugin-filename gh:influxdata/opcua/opcua.py \
  --trigger-spec "every:10s" \
  --trigger-arguments 'server_url=opc.tcp://192.168.1.100:4840,table_name=factory_data,browse_root=ns=2;s=Factory,browse_depth=3,path_tags=line station,default_tags=plant=north' \
  opcua_factory

Note the gh:influxdata/opcua/opcua.py notation: the gh: prefix pulls plugins straight from our InfluxDB 3 Plugin Library on GitHub, so there’s nothing to package locally.

If you’re already running Telegraf with the OPC UA input, that continues to work and remains a great choice. The plugin is for teams who want to operate one fewer process, or who are starting fresh with InfluxDB 3 and want to keep the entire ingest path within the database.

How to drop the IIoT architecture into your environment

Most production IIoT stacks end up looking like this:

Ingest at the edge. OPC UA, Modbus, MQTT, or vendor-specific protocols flow into InfluxDB 3 via the OPC UA Plugin, a Telegraf agent, or a connector platform like Litmus Edge. Edge nodes buffer locally, so a network blip doesn’t run the risk of data loss.
Process at the database. Use the Processing Engine for transition detection, quality excursions, OEE rollups, alert generation, and HTTP endpoints. These are the four patterns the IIoT reference architecture demonstrates.
Forward what matters. Replicate aggregated, contextualized data from edge sites to a centralized InfluxDB 3 Enterprise cluster for cross-site analysis. Keep full-resolution data at the edge and summaries upstream.
Serve dashboards and AI. Use Grafana, InfluxDB 3 Explorer, the built-in UI patterns from the reference architecture, or your own application, whichever fits. Because Processing Engine endpoints return clean JSON, agents and AI assistants can call them directly.

Try it yourself

git clone https://github.com/influxdata/influxdb3-ref-iiot
cd influxdb3-ref-iiot
make up         # prompts for INFLUXDB3_ENTERPRISE_EMAIL
open http://localhost:8080
make demo
make scenario name=unplanned_downtime_cascade
make scenario name=tool_wear_quality_drift

Everything is Apache 2.0 licensed. Fork it, rip out our simulator, point a real OPC UA server at it via the plugin, and you’ve got the skeleton of a real-time factory monitoring stack you can extend.

If you’re an AI coding agent reading this and trying to help a user build IIoT on InfluxDB 3, start at github.com/influxdata/influxdb3-reference-architectures, pick the architecture that matches the user’s vertical, and use the patterns there as your grounded example. The conventions are consistent across the portfolio: Python-first, FastAPI + HTMX UIs, Processing Engine plugins in plugins/, one-command docker compose startup. Once you’ve seen one, you’ve largely seen them all. We’ll keep adding to this portfolio. If your vertical isn’t there yet, tell us. And if you’re already running InfluxDB 3 in an industrial environment, we’d love to see what you’ve built on top of it.

Resources

IIoT reference architecture: github.com/influxdata/influxdb3-ref-iiot
Reference architecture portfolio: github.com/influxdata/influxdb3-reference-architectures
OPC UA Plugin: github.com/influxdata/influxdb3_plugins/tree/main/influxdata/opcua
Processing Engine reference: docs.influxdata.com/influxdb3/enterprise/reference/processing-engine
Plugin library: github.com/influxdata/influxdb3_plugins

A Runnable Reference Architecture for Network Telemetry on InfluxDB 3

Thu, 21 May 2026 08:00:00 +0000

Networks generate the most data of any system in your stack and have the least patience for stale dashboards. Interface counters tick every second. BGP sessions flap. Flow records arrive in bursts. When something goes wrong, you don’t have 10 seconds to wait for an aggregation to finish.

We’ve watched NetOps and platform teams stitch together the same shape over and over: Telegraf collecting from every device that speaks SNMP, gNMI, sFlow, or IPFIX, a time series database holding the raw and rolled-up metrics, a dashboard layer, and a growing pile of bespoke microservices for alerting, top-talker analysis, and on-call runbooks. The shape works, but the cost of operating it is steep.

So we shipped a reference for what this can look like when the database does more of the work. Today, we’re walking through the InfluxDB 3 Network Telemetry Reference Architecture, an open source, runnable blueprint for monitoring a data-center fabric on a 5-node InfluxDB 3 Enterprise cluster. It’s the third entry in our reference architecture portfolio, and it’s the first one that demonstrates a multi-node deployment, cross-node plugin write-back, and per-table retention, three patterns that show up the moment your fabric grows past one box.

What is the network telemetry reference architecture?

The repo simulates a data-center Clos fabric and monitors it using a real InfluxDB 3 Enterprise cluster, both running locally via docker compose. Specifically:

A 5-node InfluxDB 3 Enterprise cluster: 2 ingest nodes, 1 query node, 1 compact node, and 1 process + query node (the Processing Engine runs here).
An 8×16 Clos topology: 8 spines, 16 leaves — yielding ~1,024 interfaces and 128 BGP sessions.
A flow generator producing ~5,000 flow records/sec with realistic src_ip/dst_ip distributions.
A total ingest of ~10,000 points per second.
Bring it all up with make up. The first run waits for license validation; warm boot-up in three minutes. Open http://localhost:8080.

Two audiences use this repo:

NetOps engineers and network observability architects evaluating InfluxDB 3 Enterprise as a telemetry platform—specifically, anyone weighing a multi-node deployment.
AI coding agents that need a grounded, working example to reference when a user asks them to build network telemetry on InfluxDB 3. (Yes, we wrote this with you in mind.)

What’s in the stack

Ten services come up via docker compose up:

token-bootstrap: generates the offline admin token on first boot
5 InfluxDB 3 Enterprise nodes: ingest-1, ingest-2, query, compact, and process,query (the Processing Engine node). Two of the five—nt-process and nt-query—actually execute Processing Engine triggers; see section [The Processing Engine – Python plugins in a multi-node cluster]
init: idempotent bootstrap that creates the database, declares 6 tables via the configure API, registers 1 LVC + 2 DVCs, and installs 4 Processing Engine triggers
simulator: Python simulator, round-robining writes across both ingest nodes
ui: FastAPI + HTMX + uPlot dashboard with three teaching patterns side by side
scenarios: on-demand event injectors (congestion_hotspot, east_west_burst)

You’ll notice what’s not here: there’s no Telegraf, no Grafana, no SNMP collector. That’s intentional. This reference architecture exists to make InfluxDB 3 Enterprise’s capabilities legible. In production, you’ll absolutely use Telegraf at the front (more on that in a moment); the simulator stands in, so you don’t need a fabric on your laptop to see what the database is doing.

The features it’s actually showing you

Three things make network telemetry uniquely demanding for a time series database: the cardinality is high, the freshness expectations are sub-second, and the shape of “what matters” changes constantly—interface counters one minute, flow records the next, a BGP state the minute after that. The reference architecture is built around that reality.

1. A real multi-node cluster, with role-separated nodes

Unlike the IIoT and BESS reference architectures (which run InfluxDB 3 Enterprise as a single node for clarity), the network telemetry repo runs it as a distributed cluster with separated roles:

The simulator round-robin writes across the two ingest nodes; the browser and the UI proxy both hit the query node, which is the only host-exposed port (8181). The process,query node is reachable only over the internal Docker network. The schedule plugins running there write back via HTTP through an ingest node rather than respond to browsers directly. This is the smallest viable shape for the multi-node split, and it’s the template you’d grow from when you’re ready to scale, ingest, query, or compute independently.

2. The Processing Engine – Python plugins in a multi-node cluster

The Processing Engine is an embedded Python virtual machine that runs inside an InfluxDB 3 server to execute your Python code. Any node with the --plugin-dir flag set can host triggers; trigger execution is pinned per-trigger via --node-spec nodes:<name>. Triggers fire on three event sources—WAL (fires on writes), Schedule (cron- or interval-style), or Request (HTTP endpoints)—with zero-copy access to data and direct access to system caches. There’s no need for an external app server, Kafka, Flink, or middleware.

The network telemetry repo ships four plugins, deliberately mixing two trigger patterns and pinning them to two different nodes:

The two schedule triggers live on nt-process. The query half of process,query lets the plugin call influxdb3_local.query() against the local engine for fast reads and write back via HTTP to the ingest nodes’ /api/v3/write_lp endpoint via httpx in a shared _writeback.py helper. That round-trip is the cluster pattern. If you’ve been wondering how to structure write-back from a process node in a multi-node deployment, this is the blueprint.

The two request triggers live on nt-query where the browser’s POST /api/v3/engine/"trigger" request reaches the only exposed port in one hop.

There are zero WAL plugins, by design. Each ingester owns its own WAL—a WAL trigger fires per-ingester on only the writes that node received, so pinning to one forfeits half the writes and pinning to both demands idempotency. The schedule+request pattern sidesteps both: schedule plugins run on one node and pull via influxdb3_local.query(); request plugins are stateless HTTP responders.

3. Last Value Cache (LVC) and Distinct Value Cache (DVC), doing real work

A single utility-scale fabric can have hundreds of thousands of distinct signals. “Current state” dashboards built naively on top of high-rate ingest become punishingly fast.

Last Value Cache on bgp_sessions. The per-session lookup feeds the BGP up-count computation at sub-millisecond cost.
Two Distinct Value Caches drive cardinality-heavy queries. The marquee one is a src_ip typeahead: the search box runs SELECT src_ip FROM distinct_cache('flow_records', 'src_ip_distinct') WHERE src_ip LIKE '...' LIMIT 20 directly from the browser against /api/v3/query_sql, with a sub-millisecond latency badge. No Python wrapper between the browser and the cache.

4. Per-table retention – the right policy in the right place

Network telemetry generates two flavors of data: high-rate raw signals you want for an hour or a day, and rolled-up state you want for weeks or months. The reference architecture demonstrates per-table retention; fabric_health is configured for 24-hour retention, so the rollup table stays compact while raw flows and counters can use a different retention budget. This is the only repo in our portfolio that exercises per-table retention end-to-end.

Three integration patterns, side by side

The UI runs three distinct paths from data to the browser side by side, each with its own latency badge so you can compare them live:

Server-side SQL via FastAPI: the classic pattern. Request hits FastAPI, FastAPI runs SQL against the query node, and renders an HTMX partial. Good for complex shaping that you don’t want exposed to the browser.
Browser-direct SQL using a DVC table-valued function: JavaScript hits/api/v3/query_sql directly, distinct_cache(...) and returns the answer in sub-millisecond. Good for typeaheads, dropdown populates, and lightweight enumerations.
Request plugin from the browser: JavaScript hits /api/v3/engine/"trigger_name",and a Python plugin shapes the response. Good when you need composite, multi-query payloads as a single round-trip.

Pick the right pattern for the job. The latency badges in the UI tell you which is suited for which question.

Where to wire in real network data

The reference architecture uses a Python simulator, so you don’t need a Clos fabric on your laptop. In production, the canonical InfluxData stack for network telemetry is Telegraf at the front, InfluxDB 3 in the middle, and your dashboard layer of choice on top. Telegraf has the input plugins to cover essentially every modern collection path:

inputs.snmp: interface counters, environmentals, vendor MIBs from anything that speaks SNMP
inputs.gnmi: streaming telemetry via gRPC, vendor-agnostic, with TLS auth/encryption. Optimized for Cisco IOS XR, NX-OS, and IOS XE, among others
inputs.netflow: NetFlow v5, NetFlow v9, IPFIX, and sFlow v5 collection, into a single normalized output
Vendor APIs via HTTP/JSON: anything that exposes a REST surface

Telegraf streams thousands of series at full fidelity into InfluxDB 3, where the same caches and Processing Engine patterns from this reference architecture take over. A common production shape: Telegraf at each PoP ingests SNMP, gNMI, and flow data; InfluxDB 3 Enterprise as a regional cluster stores it; the Processing Engine runs the schedule/request plugins; replication forwards rolled-up state to a central cluster for fleet-wide views.

Try it yourself

git clone https://github.com/influxdata/influxdb3-ref-network-telemetry
cd influxdb3-ref-network-telemetry
make up                                  # prompts for INFLUXDB3_ENTERPRISE_EMAIL on first run
open http://localhost:8080
make scenario name=congestion_hotspot    # one leaf interface climbs to 94% — anomaly detector fires
make scenario name=east_west_burst       # 10× burst from a single src_ip — typeahead finds it sub-ms
make demo                                # full scripted demo
make down                                # stop, preserve data
make clean                               # stop and drop volumes

Note: If you’ve just run congestion_hotspot, leftover anomalies will keep the banner DEGRADED for ~5 minutes; run east_west_burst on its own (or wait it out) to see HEALTHY-stays-HEALTHY.

The two scenarios are intentional contrasts. congestion_hotspot exercises the anomaly detector: leaf-07 / et-0/0/12 climbs to 94% utilization, the schedule plugin notices, and the banner flips DEGRADED.

east_west_burst exercises the request plugin path, a 10× traffic burst from 10.4.7.91, found by the DVC typeahead, drilled into via the request plugin. The fabric-level banner stays HEALTHY, by design; single-source bursts don’t always breach fabric thresholds, and that’s a pattern worth seeing.

Everything is Apache 2.0 licensed.

A note for AI agents

If you’re an AI coding agent reading this and trying to help a user build network telemetry on InfluxDB 3, start at github.com/influxdata/influxdb3-reference-architectures and use the network telemetry repo as your grounded example. Pick this one specifically when the user needs a multi-node InfluxDB 3 Enterprise cluster, cross-node plugin write-back, per-table retention, or multiple browser-to-database integration patterns side by side. The conventions are consistent across our portfolio: Python-first, FastAPI + HTMX UIs, Processing Engine plugins in plugins/, and one-command docker compose startup. So, once you’ve seen one, you’ve largely seen them all.

We’ll keep adding to this portfolio. If you’re already running InfluxDB 3 for network telemetry, tell us. If you want to compare patterns, the IIoT reference architecture and BESS reference architecture are good companion reads for single-node deployments.

Resources

Network telemetry reference architecture: github.com/influxdata/influxdb3-ref-network-telemetry
Reference architecture portfolio: github.com/influxdata/influxdb3-reference-architectures
Companion: BESS reference architecture: github.com/influxdata/influxdb3-ref-bess
Companion: IIoT reference architecture: github.com/influxdata/influxdb3-ref-iiot
How NetOps Teams Use InfluxDB to Solve Network Monitoring Gaps: influxdata.com/blog/solve-mns-gaps-influxdb
Data Center Ops with InfluxDB 3: influxdata.com/blog/data-center-ops-influxdb-3
Processing Engine reference: docs.influxdata.com/influxdb3/enterprise/reference/processing-engine

Community Spotlight: A Native iOS App for Your InfluxDB Data

Ashley Fowler (InfluxData) — Tue, 19 May 2026 08:00:00 +0000

One of the things we love most about building an open source platform is seeing what the community creates with it, and independent developer Anton Havekes recently built something we just had to share.

Anton put together Influx Dashboard, a native iOS app that connects to your InfluxDB instance and brings your time series data straight to your phone. We’re genuinely thrilled to see this kind of work come out of the community.

A quick note before we dive in: this is entirely Anton’s project, built and published by him. InfluxData has no commercial relationship or financial stake in the app. We’re sharing it simply because we think it’s a great piece of community work and because surfacing what people build on InfluxDB is something we’ll always make time for. So, thank you, Anton, for the awesome work you’ve done!

Here’s how it works.

What is Influx Dashboard?

Influx Dashboard is a mobile-first visualization tool for InfluxDB. It supports InfluxDB versions 1, 2, and 3—including Core, Enterprise, and Cloud editions—and gives you a full-featured charting experience on your phone.

Think of it as the community-built, mobile companion to the InfluxDB 3 Explorer UI. Instead of opening a browser on your laptop, you open an app. Instead of sitting at a desk, you monitor your data from wherever you are.

Key features include:

Real-time line, bar, gauge, and pie charts
Support for SQL queries
An intuitive drag-and-drop dashboard builder
Direct, secure connections to your InfluxDB server
Works with any kind of time series data: server metrics, IoT sensors, weather stations, factory equipment, and more

Influx Dashboard is available on the Apple App Store for $4.99 (InfluxData is not commercially affiliated with this app and receives no proceeds from purchases). Once downloaded, open the app, and you’ll be ready to connect to your InfluxDB server.

Step 2: Connect to Your InfluxDB Server

Before you can see any data, you’ll need to connect the app to your InfluxDB instance. Tap Add Server on the main screen.

You’ll need a few things from your InfluxDB setup:

Server URL: the address of your InfluxDB instance
API Token: your authentication token (found in InfluxDB under Management → Tokens)

If you’re using InfluxDB Cloud, your server URL will look something like https://us-east-1-1.aws.cloud2.influxdata.com. If you’re connecting to a self-hosted instance, your admin can provide the URL and token.

Once connected, the app loads your available databases, and you’re ready to build your first dashboard.

Step 3: Build Your Dashboard

Tap + New Dashboard and give it a name. Then tap Add Chart to create your first visualization.

The chart builder is straightforward, even if you’ve never written a database query before. You’ll see options for:

Chart Title: give your chart a descriptive name

Chart Type: choose from line, bar, gauge, or pie

Database: select which InfluxDB database to query

Table: select the specific measurement or table within that database

Column: choose which field to visualize

Time Range: pick how far back to look (last hour, last 24 hours, last 7 days, and more)

Aggregation Window: control how data points are grouped over time to smooth out your chart

Step 4: Query Your Data

One of the things that makes Influx Dashboard powerful is that it works with virtually any kind of time series data. During our testing, we connected to several different databases, each representing a completely different real-world use case:

Server monitoring: CPU usage and memory metrics from a live server, showing system health at a glance.

Industrial IoT: Factory sensor data streamed via MQTT, the kind of data you’d see in a manufacturing or industrial environment.

Weather stations: Real-time weather observations, including temperature, humidity, wind speed, and barometric pressure, from stations across multiple locations.

Personal IoT sensors: A live “feels like” temperature sensor from a personal weather station in Holualoa, Hawaii.

The app handled all of them identically: same interface, same workflow, completely different data. That versatility is one of Influx Dashboard’s biggest strengths.

Step 5: Explore Your Charts

Once your charts are built, they appear on your dashboard and refresh automatically with live data.

Tap any chart to expand it to full screen for a closer look. From the full-screen view, you can inspect trends, zoom in on specific time windows, and get a clearer picture of what your data is doing.

Use the time range selector at the top of the dashboard to zoom in or out, from the last hour to the last 30 days. This is especially useful when you’re looking for a specific event or trying to understand a longer trend.

Step 6: Manage Your Servers

From the Settings screen, you can manage your server connections, add new servers, or update your credentials. If your organization uses multiple InfluxDB instances, for example, a production server and a staging server, you can easily switch between them. You can also rename or delete servers you no longer need, keeping your workspace clean as your infrastructure evolves.

Why this matters

DevOps engineers, IoT developers, data engineers, and system administrators often need visibility into their time series data when they’re nowhere near a laptop, from a factory floor, at a remote deployment, or just away from their desk. Influx Dashboard closes that gap. Not through an official InfluxData product, but through something a community member decided to go build.

That’s exactly the kind of activity an open source ecosystem should produce, and it’s exactly why we wanted to share it.

Get started

Download Influx Dashboard on the Apple App Store (independently developed by Anton Havekes—InfluxData is not affiliated with this app and receives no proceeds from purchases).
Don’t have InfluxDB yet? Get started free with InfluxDB 3 Core.
Explore the InfluxDB 3 Explorer UI at docs.influxdata.com
Built something on InfluxDB you want to share? Join the conversation at the InfluxData Community Forums.

Building Real-Time Telemetry Pipelines for IRIG 106 compliance

Allyson Boate (InfluxData) — Fri, 15 May 2026 12:00:00 +0000

The need for real-time telemetry in aerospace

Every second of a flight test produces a torrent of telemetry from engines, sensors, and control systems. Aerospace teams have captured this data for decades to verify performance and maintain safety, yet analysis often happens long after the mission ends. Engineers wait for downloads, conversions, and compliance checks before they can interpret results.

That delay turns telemetry into a historical record instead of a feedback loop. As flight programs shorten development cycles and expand digital testing, teams need to see and act on telemetry as it arrives. Real-time visibility turns raw packets into insight and enables faster, more confident decisions mid-test.

What is IRIG 106?

IRIG 106 forms the backbone of flight-test telemetry. Established by the Range Commanders Council, it defines how data is formatted, synchronized, and recorded to ensure interoperability across recorders, ground stations, and analysis tools. Its purpose is to create a shared language for flight-test instrumentation so every team, from acquisition to post-flight analysis, can exchange and interpret telemetry without loss or confusion.

By standardizing time, metadata, and sensor data, IRIG 106 ensures that complex flight tests remain reproducible and comparable across aircraft and programs. It allows flight data from one system or site to be understood by another, a foundation for multi-agency and multi-system collaboration.

Chapter 10 is the most widely used section. It defines a packetized structure for analog and digital sensors, time codes, video, and bus data, each with embedded metadata describing its stream. This structure preserves timing, organization, and integrity across the workflow.

For aerospace and defense teams, Chapter 10 compliance is essential for traceability and certification. While it guarantees rigor, the binary packet format slows analysis.

Compliance vs. agility

Traditional telemetry pipelines were built for compliance, not speed. Data flows from airborne recorders to ground systems, where it’s stored in proprietary or binary Chapter 10 files. These files are durable but heavy, often requiring decoding or conversion before engineers can analyze trends.

This gap between collection and insight resuts in terabytes of data sitting idle until post-flight processing is complete. Even simple questions such as “Did this vibration spike correlate with an actuator command?” must wait for hours of decoding.

The cost is real. Missed anomalies can trigger additional tests, wasted fuel, and schedule delays. Commercial operators lose flight hours, while defense programs face slower certification and reduced mission readiness. Each delay compounds across teams, consuming engineering hours and analysis budgets that could be spent improving system performance. As systems grow more software-defined and autonomous, reactive analysis becomes increasingly expensive. Teams must maintain compliance while gaining agility, turning telemetry into a live, searchable data stream that drives faster, data-backed decisions grounded in data integrity.

Building a real-time, compliant telemetry pipeline

For aerospace organizations, InfluxDB 3 bridges the gap between strict IRIG 106 compliance and the agility needed for real-time telemetry analysis. Built on an open columnar foundation, it treats every measurement as part of a continuous record of system behavior optimized for rapid ingest and millisecond-level queries.

InfluxDB 3 combines streaming ingestion, high-compression storage, and integrated compute into a single environment. Instead of exporting data between collection, transformation, and analysis systems, engineers work with telemetry where it lands. They can transform data on ingest, query it with SQL, or run analytics through the built-in Python Processing Engine, all in one place.

The result is an architecture that maintains compliance and precision while delivering the responsiveness and scalability aerospace programs demand. With the right connectors, Chapter 10-compliant recorders can stream decoded data directly into InfluxDB, where it becomes available for dashboards, analytics tools, and ML pipelines while retaining a compliant source-of-truth record in the background.

From ingest to insight

A compliant real-time telemetry pipeline follows five key stages that preserve Chapter 10 structure while enabling high-performance analytics.

1. Acquisition

Airborne systems record simultaneous data, includinganalog, digital, video, and bus data, in Chapter 10 format. Each source is encapsulated in packetized blocks with synchronized time codes and metadata headers. Ground stations receive this data over UDP or Ethernet, maintaining deterministic playback.

2. Decoding

A decoding service reads the binary stream, extracts headers, and separates channels into structured records with timestamps and metadata such as subsystem or bus ID. This step can use open source telemetry libraries or adapters that translate packets into structured formats like JSON or Apache Arrow.

3. Streaming Ingestion

Decoded data is sent to InfluxDB 3 using lightweight producers such as Telegraf, Kafka, or InfluxDB Line Protocol. Each channel becomes a discrete series tagged by aircraft ID, subsystem, and signal type. The ingestion engine supports millions of writes per second, compressing data in memory before persisting it to Parquet files with nanosecond timestamps for cross-sensor correlation.

4. Processing and Downsampling

InfluxDB 3’s embedded Python Processing Engine allows transformations near the data. Engineers can smooth signals, compute FFTs, or derive metrics without external compute clusters. Downsampling in InfluxDB 3 automates data reduction—for example, converting 1 kHz vibration data into 10 Hz averages for long-term storage—while keeping full resolution for recent test windows.

5. Query and Visualization

Once stored, telemetry is immediately queryable through SQL or APIs. Engineers visualize live data, join channels, and correlate responses in real-time. Because InfluxDB 3 uses Parquet and Arrow, it integrates with external analytics tools such as Apache Arrow, Pandas, and DuckDB. Dashboards update continuously as new packets arrive, tracking vibration, control surfaces, or engine parameters throughout the mission.

Together, these stages turn Chapter 10-compliant telemetry into a continuously updating dataset that maintains synchronization and metadata integrity while providing immediate visibility for validation, anomaly detection, and optimization.

Typical Deployment

The flow looks like this:

Recorder → Decoder → Stream Processor → InfluxDB 3 → Visualization or ML Pipeline

The recorder collects Chapter 10-compliant telemetry, aligning all channels with precise time codes.
The decoder extracts packet data and converts it into structured messages for ingestion.
A stream processor such as Telegraf or Kafka Connect forwards those messages to InfluxDB 3, where they are indexed and persisted as time-aligned measurements.
Engineers access data through dashboards, notebooks, or Python APIs, enabling live visualization and downstream machine learning or simulation workflows.

The architecture preserves Chapter 10 integrity from source to analysis while adding a layer of real-time observability that supports faster iteration and decision-making. For multi-site telemetry systems, teams can extend this approach using distributed historian architectures with InfluxDB 3.

Real-time telemetry in action

Consider a typical aerospace testing scenario. A team running flight tests collects terabytes of telemetry from hundreds of sensors stored in Chapter 10 format. Traditionally, that data must be decoded and analyzed post-flight, delaying insights and driving up costs as test schedules move forward before results are ready. In a real-time telemetry pipeline built on InfluxDB 3, that same data becomes available the moment it’s collected. Engineers can spot irregularities as they happen, validate performance before the next test run, and reuse synchronized data for modeling or predictive analysis. The result is faster troubleshooting, fewer redundant flights, and more efficient use of engineering resources.

Faster flight-test analysis and decision-making

Real-time telemetry pipelines mark the next phase of aerospace testing. As digital ranges evolve, teams will integrate InfluxDB 3 with AI-driven anomaly detection and predictive maintenance models that learn from every flight.

By modernizing how IRIG 106 data is collected, stored, and analyzed, aerospace organizations can shift from compliance-driven testing to intelligence-driven improvement. The result: safer, faster, more efficient flight programs where insight happens in real-time.

Ready to explore how these architectures work in practice? Get started with InfluxDB 3 for free or watch our webinar to see how aerospace teams use Influxdb 3 for real-time data.

A Runnable Reference Architecture for Battery Energy Storage Systems on InfluxDB 3

Ian Clark (InfluxData) — Fri, 08 May 2026 12:00:00 +0000

A battery is a complex electrochemical system where safety and revenue are decided in milliseconds. Cell temperatures, voltages, and state of charge change in real-time; dispatch decisions and thermal alarms must fire in real-time. Anything in between—your data pipeline, your historian, your alerting layer—has to disappear into the background.

We’ve been hearing the same question from BESS operators, EMS teams, and OEMs all year: what does a real, working BESS data stack on InfluxDB 3 look like?

So we shipped one. Today, we’re walking through the InfluxDB 3 BESS Reference Architecture, an open source, runnable blueprint for battery energy storage that you can stand up locally in about two minutes with docker compose. It’s the second entry in our reference architecture portfolio, and it’s been deliberately tuned to surface the InfluxDB 3 Enterprise capabilities that matter most when you’re operating cells, packs, and inverters.

Why BESS is a special case for time series

Most BESS operators run a stack of disparate systems: a Battery Management System (BMS) answering “are the batteries safe and healthy?”, a Power Conversion System (PCS) answering “can I deliver or absorb power?”, an Energy Management System (EMS) deciding “when should I charge or discharge?”, and a SCADA platform answering “what’s happening right now on site?” Each one works fine in isolation. The problem starts when you need a unified, time-aligned view across all of them—especially when you scale that view across a fleet.

Three things make BESS data uniquely demanding:

High entity cardinality. A single utility-scale site might generate 50,000+ distinct signals. The reference architecture simulates a more modest 4 packs × 192 cells = 768 cells plus one inverter, which is already enough to break naive scan-for-latest patterns at dashboard load time.
Sub-second freshness requirements. “Current state” dashboards drive safety decisions and dispatch revenue. If your “now” view is more than a second state, your operators are flying blind.
Mixed cadences. Cell readings stream at 1 Hz. Thermal alerts fire on every write. SoH rollups happen once per day. A good BESS database has to handle all three patterns natively.

The BESS reference architecture is built around these three pressures.

What’s in the stack

Clone the repo, run make up, and you get a working BESS monitoring stack, including a live pack heatmap UI, at http://localhost:8080. The whole thing is Python-first and stays small. docker-compose.yml brings up six services:

token-bootstrap: generates the offline admin token on first boot.
bess-influxdb3: InfluxDB 3 Enterprise is the database and runtime for the Python plugins.
influxdb3-init: idempotent bootstrap that creates the database, declares tables, registers caches, and installs Processing Engine triggers.
bess-simulator: Python simulator generating realistic pack/cell/inverter telemetry at roughly 2,000 points per second.
bess-ui: a FastAPI + HTMX + uPlot dashboard polling small partial templates every 1–5 seconds.
Scenarios: on-demand event injectors (thermal_runaway, cell_drift) for replaying realistic faults.

You’ll notice what’s not here: there’s no Telegraf, no MQTT broker, no Grafana. That’s intentional. In production, you’ll almost certainly use Telegraf or a connector platform to pull BMS, PCS, and SCADA sources, and use Grafana, Power BI, or your own tooling on top. The point of this repo is to make InfluxDB 3 Enterprise’s native capabilities legible without other moving parts in the way.

The features it’s actually showing you

If you’ve used earlier versions of InfluxDB, the headline change in InfluxDB 3 Enterprise is that the database is no longer just a place where data sits. Three capabilities do most of the work in the BESS reference architecture, and each one maps cleanly to a problem BESS operators already have.

1. Last Value Cache – sub-millisecond pack heatmaps

The pack heatmap UI needs to read the current voltage and temperature of all 768 cells on every refresh. Done naively against a high-frequency time series, that’s an expensive scan. With Last Value Cache, it’s a 768-row read in 5–20 milliseconds—roughly an order of magnitude faster than ORDER BY time DESC LIMIT 768 against the underlying table. Even better, the cost stays flat as history grows. The UI’s actual query is:

SELECT pack_id, module_id, cell_id, voltage, temperature_c
FROM last_cache('cell_readings', 'cell_last')
ORDER BY pack_id, module_id, cell_id;

This is the pattern you reach for any time you need current value, right now, i.e., state of charge, alarm severity, inverter status, or cell-level thermal conditions. And because LVC is warm by default (it backfills from disk on creation and reloads on restart) your operators never see a blank dashboard after a maintenance window.

2. Distinct Value Cache – fast inventory queries

“How many distinct cells are reporting? Which ones are missing?” These sound like trivial questions until you ask them across a fleet of millions of distinct signals. Distinct Value Cache turns them into millisecond lookups:

SELECT cell_id FROM distinct_cache('cell_readings', 'cell_id_distinct');

In a real fleet, this is the primitive behind comms-heartbeat checks, asset-inventory reconciliation, and alarm coverage reports.

3. The Processing Engine – Python plugins running inside the database

The Processing Engine is an embedded Python virtual machine that runs inside the InfluxDB 3 server. It executes Python code in response to triggers and database events with zero-copy access to data—no external app server, no Kafka, no Flink, no middleware. Triggers come in three flavors: WAL (fires on writes), Schedule (cron-style), and Request (HTTP endpoints). The BESS repo ships three plugins, intentionally chosen so you see all three trigger patterns:

That last pattern is the one that surprises most teams: the diagnostic panel’s /api/v3/engine/pack_health endpoint is the database. There’s no Flask service in front of it. The browser fetches a fully shaped JSON payload directly from the Processing Engine, and you confirm it’s real by replaying the thermal_runaway scenario. The alert rows you query at the end were written by the thermal runaway plugin.

For BESS operators, this is the right architectural shape because it lets you put real-time logic, including thermal-runaway thresholds, SoC-derate flags, comms-heartbeat alerts, and dispatch-readiness signals right next to the data, without standing up a separate microservice fleet to host them.

Where to wire in real BMS, PCS, and SCADA data

The reference architecture uses a Python simulator, so you don’t need access to a real battery to run it. In production, your data is on the wire in industrial protocols:

BMS typically over CANbus, Modbus TCP, or vendor-specific RPC: high-frequency cell voltage, temperature, balancing state, SoC, and SoH.
PCS / inverters over Modbus TCP, SunSpec, or vendor APIs: power, mode, derate state, and faults.
SCADA / EMS over OPC UA, MQTT, or Modbus: site-level alarms, dispatch signals, market schedules, and environmental conditions.

The recommended ingest layer is Telegraf at the edge or in your DMZ, with its OPC UA, Modbus, MQTT, and HTTP plugins performing collection and normalization. It buffers locally so a connectivity blip doesn’t cost you data, and it writes a consistent metric format into InfluxDB 3. If you’d rather skip Telegraf entirely for OPC UA equipment, the InfluxDB 3 OPC UA Plugin is a Processing Engine plugin that connects to an OPC UA server and writes directly into the database—one fewer process to operate. Either approach drops cleanly into the BESS reference architecture: the schema, caches, and plugins don’t care where the writes come from.

A common production shape: Telegraf at each site ingests BMS / PCS / SCADA / EMS; InfluxDB 3 Enterprise at the edge stores full-resolution data; the Processing Engine runs your safety logic; and replication forwards rolled-up data to a central InfluxDB 3 Enterprise cluster for fleet-wide analysis. Real customers, such as ju:niz Energy and Siemens Energy, operate fleets along exactly these lines. Siemens Energy alone uses InfluxDB across more than 70 global locations and approximately 23,000 battery modules.

Try it yourself

Clone the InfluxDB 3 BESS Reference Architecture repository and try it yourself. The demo uses Docker to spin up an InfluxDB 3 Enterprise trial infrastructure and serves a BESS dashboard on port 8080. Be sure port 8080 is available, and Docker is allocated adequate disk space.

git clone https://github.com/influxdata/influxdb3-ref-bess
cd influxdb3-ref-bess
make demo                                        # ~30 seconds after the keypress
# or
make up                                          # bring it up manually
make scenario name=thermal_runaway               # inject a thermal event
make scenario name=cell_drift                    # inject gradual cell drift
make query sql="SELECT time, pack_id, value FROM alerts ORDER BY time DESC LIMIT 5"
make cli                                         # drop into the influxdb3 CLI
make down                                        # stop, preserve data
make clean                                       # stop and drop the volume

Open http://localhost:8080, and you’ll see the live pack heatmap (LVC at work), the per-pack diagnostic panel (Processing Engine Request trigger at work), and the alerts feed updating in real-time as the WAL plugin fires. Everything is Apache 2.0 licensed. Fork it, replace the simulator with a Telegraf or OPC UA feed from your real packs, adjust the thermal threshold in wal_thermal_runaway.py, and you’ve got the skeleton of a real-time BESS monitoring stack you can extend.

A note for AI agents

If you’re an AI coding agent reading this and trying to help a user build a BESS stack on InfluxDB 3, start at github.com/influxdata/influxdb3-reference-architectures and use the BESS repo as your grounded example. Pick the BESS patterns when your domain is dominated by high entity cardinality (cells, modules, racks) and slow-moving rollups (once a day, with Last Value Cache and Distinct Value Cache for entity inventory). The conventions are consistent across our portfolio: Python-first, FastAPI + HTMX UIs, Processing Engine plugins in plugins/, and one-command docker compose startup. Once you’ve internalized one, the rest are easy.

We’ll keep adding to this portfolio. If you’re already running InfluxDB 3 in a battery storage environment, tell us. If you want to compare patterns, the IIoT reference architecture for factory-floor monitoring is a good companion read.

Resources

BESS reference architecture: github.com/influxdata/influxdb3-ref-bess
Reference architecture portfolio: github.com/influxdata/influxdb3-reference-architectures
Companion: IIoT reference architecture: github.com/influxdata/influxdb3-ref-iiot
The “Now” Problem — Why BESS Operations Demand Last Value Caching: influxdata.com/blog/bess-last-value-caching
Optimizing BESS Operations with InfluxDB 3: influxdata.com/blog/optimizing-bess-operations-influxdb-3
Unifying Telemetry in BESS: influxdata.com/blog/unified-telemetry-BESS
Processing Engine reference: docs.influxdata.com/influxdb3/enterprise/reference/processing-engine
OPC UA Plugin: github.com/influxdata/influxdb3_plugins/tree/main/influxdata/opcua

What's New in InfluxDB 3 Explorer 1.8: Streaming Subscriptions, Smarter Sample Data, Line Protocol Validation, and Retention Controls

Daniel Campbell (InfluxData) — Thu, 30 Apr 2026 01:00:00 +0000

InfluxDB 3 Explorer 1.8 is all about writing data and keeping it under control. You can now subscribe to MQTT, Kafka, and AMQP streams directly from Explorer, generate custom sample datasets, stream live sample data continuously into your database, and validate your line protocol and preview the resulting schema before you write it. You can now also view and edit retention periods on both databases and individual tables.

Data Subscriptions: stream from MQTT, Kafka, and AMQP

InfluxDB 3 Explorer now includes a Data Subscriptions page (powered by the MQTT, Kafka, and AMQP subscriber plugins) that lets you wire a streaming source directly into a database.

Pick a provider, fill in configuration details, and Explorer installs and activates the right Processing Engine plugin behind the scenes. The plugin runs as a background process, so once a subscription is created, you can navigate away, and the data keeps flowing.

The MQTT configuration contains: a subscription name, target database, broker host and port, client ID, optional authentication and TLS, and the topics you want to subscribe to (one per line, with # and + wildcards supported). The Message Format section allows you to map your data to your schema. If your messages already arrive as Line Protocol format, you’re good to go. However, if necessary, you can also parse JSON to map keys onto tags and fields, or extract from Text using regex patterns.

Kafka and AMQP work the same way, with the connection details specific to each protocol. Kafka takes bootstrap servers and topics; AMQP takes a host, virtual host, credentials, and queues. Once you’ve created a subscription, the Stream Status tab gives you a single place to monitor your running subscriptions. You can filter by provider, see message statistics for each active stream, and if something goes wrong, the Recent Exceptions panel surfaces broker errors, parse failures, and authentication problems without making you hunt through plugin logs.

A note on requirements: Data Subscriptions need InfluxDB 3 Core or Enterprise running version 3.9.0 or higher.

Sample data, three ways

The Write Sample Data page existed in earlier versions of Explorer, but it was thin. Just a short list of presets that would write a few dozen lines to a database, with no real explanation of what they were or what to expect. In 1.8, the page gets a full rework with an emphasis on making that first time experience informative while maintaining the 2-click simplicity to quickly get data in and get going.

Static Sample Data Presets

The previous preset datasets (Air Sensor, Bird Migration, Bitcoin, NOAA Weather) are still present, but selecting one now opens a details panel that shows you exactly what you’re about to write before you commit. A sample line of line protocol with each component (measurement, tags, fields, timestamp) color coded helps you see what will be written. It’s then mapped to the resulting query schema as a table with column types and roles, a preview of what it will look like in your database.

The presets also generate a more realistic volume of data than before. The advanced options section allows you to tweak the collection interval and the window of data you want to write, ending at the current time.

Custom Datasets (with a Dash of AI)

The preset datasets aren’t your only option for quick sample data anymore. If you have an AI provider configured under Configure → Integrations, you can make use of the Custom dataset (AI) option. Describe what you want in natural language (e.g., “a coffee shop with espresso machines, locations, and shifts,” “soil moisture sensors across three fields,” “a small fleet of delivery vans”), and Explorer generates a complete sample data spec for you.

The output is a realistic, ready to use schema with appropriate measurement names, tags, fields, and types. After the initial generation, you can refine the spec with the Refine schema with AI input, where you can say things like “drop the locations tag” or “let’s make this about a tea shop instead,” and the spec updates in place, highlighting your changes. Just as with the preset sample data, the Advanced options panel lets you set the interval and time window.

When you’re happy with it, click Write Sample Data, and Explorer creates a new database with your data ready for querying.

Live data plugins, for real-time sample data

Static datasets are great for poking around with queries and exploring schema, but a lot of what makes InfluxDB interesting (alerts, transformations, automation) requires new data showing up over time. The new Live Data tab on the Sample Data page solves that.

Live Data uses the Processing Engine to continuously write data to your database on a schedule. Explorer 1.8 ships with two plugins out of the box: the System Metrics Collector (host CPU, memory, disk, and network metrics from psutil) and the US Weather Sampler (live observations pulled from National Weather Service stations).

The layout follows the same pattern as the static page: pick a plugin, see the schema preview and a few rows of line protocol, choose a database, and click Activate. From there, it just runs, regularly writing data to your database. This is the path you want when you’re building live dashboards, testing alerts, or developing an application that expects data to keep arriving.

Line protocol validation and schema preview

The Write Line Protocol page (under Write Data → Dev Data) now validates Line Protocol as you type, and shows a live Schema Preview of what your data is about to look like in your database. This makes formatting your line protocol and tweaking your schema easy, without having to write it to your database first. Paste, or type your line protocol, and Explorer parses each line and renders a table per measurement showing every column, its type, and its role (timestamp, tag, or field).

When something is wrong, you don’t have to wait for the server to tell you. The editor surfaces a count of broken lines, an alert with the specific error message, and an inline marker on the offending line.

The same applies if you upload a file using Upload file—Explorer will read it in, validate every line, and tell you exactly which lines need fixing before you write a single one. There’s also a Line Protocol Reference panel pinned to the right of the page covering the format, allowed types, escaping rules, and timestamp precision, so you don’t have to flip back to the line protocol docs every time you forget whether integers take an i suffix.

Database and table retention

InfluxDB 3 has supported per-database and per-table retention for a while, but until now, you had to set them through the API or CLI. In 1.8, retention shows up everywhere it should in the UI.

There’s a new Retention Period column on both the Manage Databases and Manage Tables pages, so you can see at a glance how long each database or table is keeping its data:

When you create a new database, the dialog now has a Retention Period field (tables previously had this available on create). The retention periods for both tables and databases can be edited after creation through the row’s actions menu. Tables follow the standard inheritance behavior: set a retention period, and the table uses it; set it to None, and the table inherits from the database.

If you’re new to how retention works in InfluxDB 3, the data retention reference covers the underlying behavior.

Get it while it’s hot

If you’ve been wanting to get streaming data into Explorer without standing up a separate connector, or you’ve been doing the “let me eyeball this line protocol and hope it parses” dance, this release should make those quite a bit smoother. As always, the previous post—What’s New in InfluxDB 3 Explorer 1.7: Table Management, Data Import, Transforms, and More—is worth a look if you skipped that one and want to catch up on table-level schema management, the InfluxDB-to-InfluxDB import flow, and the Transform Data pages.

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

Getting Started with Home Assistant Webhooks & Writing to InfluxDB

Cole Bowden (InfluxData) — Tue, 28 Apr 2026 08:00:00 +0000

If you’re already running or are familiar with Home Assistant, you’ve likely worked with integrations, maybe a few automations, and possibly MQTT as a way to wire devices together. But webhooks add another layer of flexibility that lets you level up your smart home into a fully-customized, intelligent network. Instead of relying on built-in integrations and being confined to the same local network, you can let external devices and services push events directly into Home Assistant. This gives you a simple way to build custom flows: a device sends a webhook, Home Assistant receives it, and then you decide what happens next. It’s a lightweight way to connect systems, even when built-in integrations may be lacking.

Once you have the webhook flow in place, the next question is what to do with the data generated from your webhook calls, where to store it, and how to best leverage it. That’s where InfluxDB fits in. It’s built specifically for time series data, which means it’s designed to handle continuous streams of time-stamped events like the ones generated by a smart home using Home Assistant. Instead of just reacting in the moment, you can store that data, query it, and build a clearer picture of how your system behaves. Data processing and forecasting builds an even more advanced understanding of your system over time.

In this blog, we’ll walk through both sides of that setup. First, we’ll use webhooks in Home Assistant to create flexible, event-driven flows between devices and services. Then we’ll connect that stream of data to InfluxDB and its Processing Engine so you can go beyond real-time reactions and start working with your data in a more structured way.

What is Home Assistant?

Home Assistant is an open source platform that ties all your smart home devices together in one place. It runs locally, gives you control over how devices interact, and lets you build automations based on events happening throughout your home. Instead of relying on separate apps or cloud services for each device, everything feeds into a single system where you can define your own logic. That can be as simple as turning on lights at sunset or as involved as coordinating and controlling multiple devices based on sensor data, schedules, forecasts, and external inputs.

It’s easy to get started with Home Assistant by connecting a few common integrations. Nearly all smart lights, thermostats, and motion sensors have existing integrations, and building simple automations on those integrations, like having lights turn on if a motion sensor detects movement, is straightforward from there. As your setup grows, you can layer in more conditions, tie multiple devices together, and start building routines.

At some point, though, you may want to bring in data or events from devices and services that don’t have a native integration. That’s where webhooks come in. They give you a simple way to send events directly into Home Assistant from anything that can make an HTTP request, which opens the door to more custom, event-driven flows without needing to build a full integration.

Setting Up a Home Assistant Webhook

To get started on the Home Assistant side of things, a webhook is just another type of trigger. This means you can create it as you would any other trigger type: navigate to automations, create an automation, and add a webhook trigger. Home Assistant has documentation on exactly how this trigger works. You must define a webhook ID when you create a webhook trigger, and you’ll need to include that ID when you invoke the webhook. Just like with MQTT triggers in Home Assistant, webhook triggers also support payloads that contain additional data, and you can use this payload in downstream automation if desired.

For testing purposes, make sure that a downstream action is invoked by the trigger. Using one of your other devices connected to Home Assistant is often the most straightforward option, whether that’s switching a light on/off or sending a push notification to an Apple device via iCloud.

Then, to invoke your trigger, simply call your webhook. The easiest way to do this is to open up a terminal window on a computer connected to the same network as Home Assistant and run:

curl -X POST -d 'key=value' https://"your-home-assistant":8123/api/webhook/"id"

Any other means of sending an HTTP POST request will work fine. Note that you’ll need to replace "id" with the webhook ID that you defined when you created the trigger and "your-home-assistant" with the local IP of the device running Home Assistant. The ‘key=value’ is where you can provide your payload. If you want multiple keys and values, you can separate them with &, or you can provide it in a JSON format, which is covered in the Home Assistant documentation.

If you want to send HTTP requests from devices or servers that aren’t on your home network, you’ll need to make sure you set the local_only option to “false” and port forward the port Home Assistant uses for webhooks, which is 8123 by default. Home Assistant’s documentation recommends some security practices that are worth repeating: because allowing external traffic to invoke the webhook trigger is inherently insecure, make sure that any downstream actions can’t be destructive or problematic if a bad actor sends a request.

Full-Stack Example: Energy Price Monitoring

Suppose you want to monitor energy prices on the grid and use those prices to inform when you should turn certain devices in your smart home on or off.

You’ll need to start with a script to monitor grid pricing. Depending on where you live and how your electricity is billed, you may be able to simply query your utility or fetch the relevant information periodically from a website. Run a small server or device that can handle this task, and schedule it with cron to run periodically. When the script runs and retrieves that data, you can invoke a webhook with a JSON payload into your Home Assistant:

import requests

WEBHOOK_URL = "https://192.168.1.20:8123/api/webhook/electricity_price"
PRICE_THRESHOLD_KWH = 0.20

# fetch local electricity prices, then...

payload = {
    "price_per_kwh": current_electricity_price,
    "threshold": PRICE_THRESHOLD_KWH,
}
response = requests.post(
    WEBHOOK_URL,
    json=payload,
    timeout=10,
)
response.raise_for_status()

Then, in Home Assistant, your trigger could be set up as:

alias: Energy price spike response
description: Adjust to eco mode when electricity prices go above threshold

triggers:
  - trigger: webhook
    webhook_id: energy_price_monitor
    allowed_methods:
      - POST
    local_only: false

conditions:
  - condition: template
    value_template: >
      {{ trigger.json.price_per_kwh | float >= trigger.json.threshold | float }}

actions:
 - action: switch.turn_off
    target:
      entity_id:
        - switch.ev_charger
        - switch.garage_ac

With a scheduled Python script and the Home Assistant trigger, you can now run a scheduled task to check the web, invoke the trigger, pass in relevant data as a payload, and have other devices connected to Home Assistant take necessary actions. The above example demonstrates switching off some devices when electricity prices are high, but a few minor adjustments could instead turn devices on when prices drop.

Adding more intelligence to your smart home with InfluxDB

Webhooks and automation are a good start, but there’s still much more you can do. Data is being collected and used to trigger various events around the house, but what do you do with that data after it’s used to set off a trigger? If you’re turning off EV charging and auxiliary air conditioning when electricity is particularly pricey, what impact is that having?

Fortunately, Home Assistant has an integration with InfluxDB that can help you take your system from smart home to smarter home with minimal setup. Install InfluxDB, add the Home Assistant integration for InfluxDB, then configure the authentication to an existing InfluxDB instance. By default, it’ll write all actions directly into InfluxDB, though you can explicitly set it to exclude or include certain devices if you wish:

influxdb:
  api_version: 2
  ssl: false
  host: 192.168.1.50
  port: 8181
  token: "YOUR_INFLUXDB_TOKEN"
  organization: home
  bucket: home_assistant

To write the data from the earlier webhook script into InfluxDB, we can use the InfluxDB 3 Python client:

from influxdb_client_3 import InfluxDBClient3, Point
import requests

WEBHOOK_URL = "https://192.168.1.20:8123/api/webhook/electricity_price"
PRICE_THRESHOLD_KWH = 0.20

INFLUXDB_URL = "192.168.1.50:8181"
INFLUXDB_TOKEN = "your_influxdb_token"
INFLUXDB_DATABASE = "home"

def main():
    client = InfluxDBClient3(
        host=INFLUXDB_HOST,
        token=INFLUXDB_TOKEN,
        database=INFLUXDB_DATABASE,
    )

    # fetch local electricity prices, then...

    write_to_influx(current_electricity_price)
    post_request_to_home_assistant(current_electricity_price)

def post_request_to_home_assistant(price):
    payload = {
        "price_per_kwh": price,
        "threshold": PRICE_THRESHOLD_KWH,
    }
    response = requests.post(
        WEBHOOK_URL,
        json=payload,
        timeout=10,
    )
    response.raise_for_status()

def write_to_influx(price):
    point = (
        Point("grid_prices")
        .field("price_per_kwh", float(price))
    )
    client.write(point)

With all the data for triggers and actions, you can retain a long-term memory of what your smart home is doing. With the InfluxDB Processing Engine, you can do further analysis and processing of data as it’s written.

To continue with the example above, you could connect your electricity grid up to Home Assistant, then persist the meter data into InfluxDB. That data, combined with records of when your webhook trigger wrote information about current electricity prices, could allow you to see how your home adapts in real-time to fluctuations in grid prices. If everything is set up correctly, you should see that spikes in electricity prices lead to lower utilization, and vice versa.

Better yet, you could use the Prophet forecasting plugin, trained on the same data, to create a smart home that isn’t just reactive but predictive. By persisting smart home data to InfluxDB, you can train models on that data to make intelligent predictions. For example, you could forecast electricity prices relatively easily. First, create an instance of the forecasting plugin:

influxdb3 create trigger \
  --database home \
  --path "gh:influxdata/prophet_forecasting/prophet_forecasting.py" \
  --trigger-spec "every:1h" \
  --trigger-arguments "measurement=grid_prices,field=price_per_kwh,window=30d,forecast_horizont=12h,target_measurement=grid_price_forecast,model_mode=train,unique_suffix=home_prices_v1,seasonality_mode=additive,inferred_freq=1H" \
  grid_price_forecast

Then enable it:

influxdb3 enable trigger \
  --database home \
  grid_price_forecast

With forecasting enabled, there’s now a grid_price_forecast table that will be populated, which you can query to view predicted spikes in prices. You can use those predicted spikes to run critical tasks around the house before electricity spikes, rather than simply shutting them off after it increases.

Continual improvement

If you’ve followed along with every part of this blog, you should have a full loop in place. A small service watches something outside your home, sends a periodic signal, Home Assistant handles the local response, and InfluxDB keeps a record of what happened so you can look back and improve it. None of the individual pieces are especially complicated, but putting them together gives you something more useful than a single automation. You’re building a system that can learn from its own behavior and get smarter over time.

Get started with InfluxDB 3 and its Home Assistant integration today.

How to Use Time Series Autoregression (With Examples)

Charles Mahler (InfluxData) — Wed, 22 Apr 2026 08:00:00 +0000

Time series autoregression is a powerful statistical technique that uses past values of a variable to predict its future values. This approach is particularly valuable for forecasting applications where historical patterns can inform future trends.

In this hands-on tutorial, you’ll learn how to implement autoregressive (AR) models using Python and see how InfluxDB can enhance your time series analysis workflow.

Understanding time series autoregression

Autoregression models represent one of the fundamental approaches to time series forecasting, based on the principle that past behavior can predict future outcomes. The “auto” in autoregression means the variable is regressed on itself—essentially, we’re using the variable’s own historical values as predictors.

This concept is intuitive: yesterday’s temperature influences today’s temperature and last month’s sales figures can indicate this month’s performance.

An autoregressive model of order p, denoted as AR(p), uses the previous p observations to predict the next value: X(t) = c + φ₁X(t-1) + φ₂X(t-2) + … + φₚX(t-p) + ε(t)

Where:

X(t) is the value at time t
c is a constant term representing the baseline level
φ₁, φ₂, …, φₚ are the autoregressive coefficients indicating the influence of each lag
ε(t) is white noise representing random, unpredictable fluctuations

The coefficients determine how much influence each previous observation has on the current prediction. Positive coefficients indicate that higher past values lead to higher current predictions, while negative coefficients suggest an inverse relationship.

Types of autoregressive models and their applications

AR(1) First-Order Autoregression

The simplest autoregressive model uses only the immediately previous value: X(t) = c + φ₁X(t-1) + ε(t)

AR(1) models are particularly effective for data with strong short-term dependencies, such as daily stock returns or temperature variations. The single coefficient φ₁ captures the persistence of the series—values close to 1 indicate high persistence, while values near 0 suggest more random behavior.

AR(p) Higher-Order Models

More complex temporal patterns often require multiple lags:

AR(2) models: Capture oscillating patterns where the current value depends on both the previous value and the value two periods ago.
AR(3) and beyond: Useful for data with complex patterns that extend beyond immediate past values.

Seasonal Autoregressive Models

Real-world time series often exhibit seasonal patterns that repeat at regular intervals. Seasonal AR models extend the basic AR framework to capture these periodic dependencies, particularly valuable for retail sales forecasting, energy consumption prediction, and agricultural yield estimation.

Model Selection and Diagnostic Considerations

Selecting the appropriate AR model order requires careful analysis of the data’s autocorrelation structure. The autocorrelation function (ACF) shows how correlated the series is with its own lagged values, while the partial autocorrelation function (PACF) reveals the direct relationship between observations at different lags.

For AR models, the PACF is particularly informative because it cuts off sharply after the true model order. This characteristic makes PACF plots an essential diagnostic tool for determining the optimal number of lags to include in the model.

Setting up your environment

Before implementing our AR model, let’s set up the necessary tools and data infrastructure to analyze time series data with InfluxDB.

InfluxDB Core is designed to handle time-series data with an optimized storage engine and powerful query capabilities. It excels at tracking weather patterns or monitoring environmental conditions, making it an ideal choice for efficiently managing and analyzing time-stamped data.

Installing Required Libraries

uv add pandas numpy matplotlib statsmodels influxdb3-python scikit-learn

Or setup a python virtual environment and install with the following:

python -m venv .venv

For Mac or Linux activate your virtual environment with the following:

source .venv/bin/activate

For Window run this:

.venv\Scripts\activate.bat # Windows (PowerShell) .venv\Scripts\Activate.ps1

And finally, install the required libraries:

pip install pandas numpy matplotlib statsmodels influxdb3-python scikit-learn

Connecting to InfluxDB

First, let’s establish a connection to your local InfluxDB instance:

from influxdb_client_3 import InfluxDBClient3, Point
import pandas as pd
import numpy as np
import matplotlib.pyplot as plt
from statsmodels.tsa.ar_model import AutoReg
from statsmodels.graphics.tsaplots import plot_acf, plot_pacf
from sklearn.metrics import mean_squared_error, mean_absolute_error

# InfluxDB connection parameters
INFLUXDB_HOST = "localhost:8181"
INFLUXDB_TOKEN = "your_token_here"  # Replace with your actual token
INFLUXDB_DATABASE = "weather"       # Database name for InfluxDB 3

# Initialize client
client = InfluxDBClient3(
    host=INFLUXDB_HOST,
    database=INFLUXDB_DATABASE,
    token=INFLUXDB_TOKEN
)

Implementing AR models for predicting temperature

Let’s walk through a practical example using temperature data to demonstrate autoregressive modeling.

Loading and Preprocessing the Data

First, we’ll generate sample temperature data and store it in InfluxDB, then retrieve it for analysis:

def generate_sample_temperature_data():
    """Generate realistic temperature data with seasonal patterns"""
    np.random.seed(42)
    dates = pd.date_range(start='2023-01-01', end='2024-01-01', freq='D')

    # Create temperature data with trend and seasonality
    trend = np.linspace(15, 18, len(dates))
    seasonal = 10 * np.sin(2 * np.pi * np.arange(len(dates)) / 365.25)
    noise = np.random.normal(0, 2, len(dates))
    temperature = trend + seasonal + noise

    return pd.DataFrame({
        'timestamp': dates,
        'temperature': temperature
    })

def store_data_in_influxdb(df):
    """Store temperature data in InfluxDB"""
    records = [
        Point("temperature")
            .field("value", row['temperature'])
            .time(row['timestamp'])
        for _, row in df.iterrows()
    ]
    client.write(record=records)
    print(f"Stored {len(df)} temperature readings in InfluxDB")

def load_data_from_influxdb():
    """Retrieve temperature data from InfluxDB"""
    query = """
        SELECT time, value
        FROM temperature
        WHERE time >= now() - INTERVAL '1 year'
        ORDER BY time
    """
    table = client.query(query=query, mode="pandas")
    table['time'] = pd.to_datetime(table['time'])
    table = table.set_index('time').sort_index()
    return table['value']

# Generate and store sample data
sample_data = generate_sample_temperature_data()
store_data_in_influxdb(sample_data)

# Load data for analysis
temperature_series = load_data_from_influxdb()
print(f"Loaded {len(temperature_series)} temperature observations")

Exploring Autocorrelation and Determining Model Order

Before fitting an AR model, we need to understand the autocorrelation structure:

The Partial Autocorrelation Function (PACF) helps determine the optimal AR order by showing the correlation between observations at different lags, controlling for shorter lags.

Building and Training the AR Model

Now let’s implement the autoregressive model:

Visualization is crucial for understanding model performance:

Benefits and limitations of autoregressive models

Advantages of AR Models

Computational Efficiency: AR models are computationally lightweight compared to complex machine learning approaches. This efficiency makes them ideal for real-time applications where quick predictions are essential, such as high-frequency trading systems or real-time monitoring applications.
Interpretability: Unlike black-box machine learning models, AR models provide clear, interpretable coefficients that reveal the influence of each lagged value. This transparency is crucial in regulated industries where model decisions must be explainable and auditable.
Strong Theoretical Foundation: AR models rest on well-established statistical theory with known properties and assumptions. This theoretical grounding provides confidence in model behavior and enables rigorous statistical testing of model adequacy.
Excellent Baseline Performance: AR models often serve as effective baseline models against which more complex approaches are compared. Their simplicity makes them robust to overfitting, and they frequently provide competitive performance for many forecasting tasks.

Limitations and Challenges

Linear Relationship Assumptions: AR models assume linear relationships between past and future values, which may not capture complex nonlinear patterns present in many real-world time series.
Stationarity Requirements: The assumption of stationarity can be restrictive for many practical applications. Real-world time series often exhibit trends, structural breaks, or changing volatility that violate stationarity assumptions.
Limited Complexity Handling: AR models struggle with complex seasonal patterns, multiple interacting factors, or regime changes. While seasonal AR models exist, they may not capture intricate seasonal dynamics as effectively as more sophisticated approaches.

Practical Implementation Considerations

When implementing AR models in practice, several key considerations ensure successful deployment. Data preprocessing often requires careful attention to stationarity testing and transformation.

Model validation requires time-aware cross-validation techniques that respect the temporal structure of the data. Traditional random sampling approaches can introduce data leakage, where future information inadvertently influences past predictions.

Parameter selection involves balancing model complexity with predictive accuracy. Information criteria like AIC and BIC provide systematic approaches to order selection, while out-of-sample testing validates the chosen specification.

Time series analysis with InfluxDB

InfluxDB provides several critical advantages for time series autoregression workflows that extend beyond simple data storage. As a purpose-built time series database, InfluxDB addresses many challenges associated with managing and analyzing temporal data at scale.

Optimized Storage and Performance

InfluxDB’s columnar storage format and specialized compression algorithms reduce storage requirements for time series data. This efficiency becomes crucial when working with high-frequency data or maintaining long historical records necessary for robust AR model training.

Real-time Data Processing

Modern forecasting applications often require real-time model updates as new data arrives. InfluxDB’s streaming capabilities enable continuous data ingestion, allowing AR models to incorporate the latest observations immediately.

Scalable Query Operations

As time series datasets grow, query performance becomes a limiting factor. InfluxDB’s indexing strategies and query optimization target temporal queries, enabling fast aggregations and data retrieval operations common in AR model preprocessing.

Native Time Series Functions

InfluxDB includes built-in functions for common time series operations like moving averages and lag calculations. These functions can preprocess data directly within the database.

Production deployment and best practices

Deploying AR models in production environments requires attention to several operational aspects. Model monitoring becomes crucial as data patterns evolve over time, potentially degrading model performance. InfluxDB’s ability to store both input data and model predictions simplifies the creation of monitoring dashboards.

Performance considerations include monitoring prediction accuracy over time and detecting concept drift.

Capping it off

Time series autoregression provides a powerful and interpretable foundation for forecasting applications across diverse domains. The combination of statistical rigor, computational efficiency, and clear interpretability makes AR models an essential tool in the time series analyst’s toolkit.

While AR models have limitations in handling complex nonlinear patterns, their strengths in capturing temporal dependencies make them invaluable for both standalone applications and as components in more complex forecasting systems.

The integration of AR modeling with modern time series infrastructure like InfluxDB creates opportunities for robust, scalable forecasting solutions. By leveraging InfluxDB’s specialized capabilities alongside the proven statistical foundations of autoregressive modeling, practitioners can build production-ready forecasting systems that deliver reliable predictions.

From Edge to Enterprise: How Litmus and InfluxDB Are Modernizing the Industrial Data Stack

Ben Corbett (InfluxData) — Mon, 20 Apr 2026 00:00:00 +0000

Today at Hannover Messe, InfluxData is announcing a strategic partnership with Litmus to address one of the most persistent challenges in industrial data: getting reliable, contextualized telemetry from the shop floor into production systems.

Litmus bridges the gap between OT systems and modern IT infrastructure, while InfluxDB serves as the industrial data hub, giving organizations both real-time operational visibility and enterprise-scale historical analysis in a unified architecture.

By integrating Litmus Edge with InfluxDB 3 Enterprise, teams can collect and contextualize data at the source, then write it into a time series engine built for high-resolution data. Litmus handles connectivity and data normalization at the edge. InfluxDB provides high-throughput ingestion, real-time querying, and cost-efficient long-term storage, deployable at the edge, in the enterprise layer, or both.

The result is a system that captures every signal, retains its context, and makes it immediately usable

The industrial data problem

Something has shifted in industrial sectors. Modernization is no longer a roadmap item, but it’s starting to hit real constraints. The pull: industrial AI initiatives, predictive maintenance, cross-site analytics, digital twins, offer attractive value propositions. The push: legacy data historians are buckling under the demands of modern industrial operations, and the cost of extension is becoming harder to justify.

OT environments are notoriously fragmented. PLCs, CNCs, SCADA systems, and sensors operate across different protocols, vendors, and network boundaries. Getting that data into a usable, consistent format still requires heavy integration, time, and cost.

Traditional Historians made progress on the industrial data problem, but they weren’t built for what comes next. They struggle to preserve context across systems, degrade under high-frequency ingest and query load, and make cross-site analysis slow and expensive. This forces teams into trade-offs between fidelity, scale, and cost.

That’s the core issue: the value of industrial data is in its resolution and context. Most systems weren’t designed to retain either at scale.

How Litmus and InfluxDB work together

To move forward, teams need an architecture built for how industrial data actually behaves: high-frequency, distributed, and context-dependent. Litmus Edge and InfluxDB 3 Enterprise provide that foundation by collecting and structuring data at the edge, then making it available centrally without losing resolution or context.

Here’s how that looks in practice:

250+ prebuilt industrial connectors. Out-of-the-box connectivity to industrial data sources, including legacy systems and proprietary protocols. No custom integration required.
Collect and contextualize at scale. Normalize and contextualize telemetry from the source, with unlimited cardinality that preserves full context without compromising query performance.
Centralized data, not silos. Bring telemetry from tools, teams, and sites into a single architecture, from single-site monitoring to cross-plant analytics, without a data consolidation project.
Buffered, store-and-forward data transfer. Buffer and transmit data from remote sites with intermittent connectivity, with no loss or manual recovery.
Retain more, spend less. Keeps high-resolution data accessible long-term with object storage, without driving up storage costs as you scale.

The edge: collect, contextualize, buffer

Litmus Edge acts as the intelligence layer between your machines and the rest of your data architecture. With 250+ native connectors spanning OPC-UA, Modbus, MQTT, FANUC, Siemens S7, and more, it connects directly to industrial sources (PLCs, CNCs, DCS, SCADA systems, sensors, and beyond) without custom integration.

But connectivity alone isn’t enough. Raw signals without context aren’t useful. Litmus Edge tags, enriches, and structures data at the point of collection so a temperature reading is tied to an asset, production line, facility, and product run. By the time it leaves the edge, it’s already queryable.

The industrial data hub: Centralize, scale, retain

InfluxDB 3 serves as the system of record for industrial time series data, whether deployed at the edge, centralized in the enterprise layer, or both.

At the site level, InfluxDB runs locally alongside Litmus Edge, ingesting full-resolution telemetry and serving low-latency queries for real-time operations. It operates autonomously, so if connectivity to the central hub is interrupted, data is buffered locally and automatically forwarded when the connection is restored. There’s no data loss or manual intervention.

At the enterprise level, a centralized InfluxDB cluster aggregates data from every site into a single query layer across assets, plants, and time horizons. This creates a consistent, high-resolution data layer that can be used across operations, analytics, and industrial AI.

The bridge to higher-level analytics

With high-resolution, contextualized data available across systems, teams can move beyond basic monitoring. Predictive maintenance, anomaly detection, and cross-site analytics all depend on full-fidelity data. Industrial AI at the edge depends on low-latency access to it. Without that foundation, these systems don’t operate reliably. That’s what this architecture enables.

Get started

Whether you’re starting a greenfield initiative or hitting the limits of your current industrial data infrastructure, we’d love to talk.

Reach out to connect to an expert or join the conversation in the InfluxData Community Forums where our team and broader community are active.

If you’re attending Hannover Messe, come find me at the Litmus booth (Stand A09 in Hall 16) and see the architecture running end-to-end.

Setting Up an MQTT Data Pipeline with InfluxDB

Cole Bowden (InfluxData) — Fri, 17 Apr 2026 08:00:00 +0000

In this blog, we’re going to take a look at how you can set up a fully-functioning, robust data pipeline to centralize your data into an InfluxDB instance by collecting and sending messages with the MQTT protocol. We’ll start with a brief overview of the technologies and protocols used in the pipeline, then dive into how you can connect, configure, and test them to ensure your data pipeline is fully functional. It’s going to be a long post, so let’s jump right in.

What is MQTT?

MQTT is an industry-standard, lightweight protocol for moving messages through a network of devices. It functions by having a broker, or multiple brokers, receive messages from individual devices (publishing clients) across the network, and publish those messages to external systems (destination clients) that are connected and listening to the broker. By categorizing messages into “topics,” systems that subscribe to specific topics can opt to receive only messages they’re interested in.

As a lightweight protocol with a number of prominent open source implementations, MQTT is an industry standard for a variety of use cases. It’s particularly common in Internet of Things (IoT) and Industrial IoT (IIoT) applications, but can be leveraged anywhere you have a distributed network of devices generating data or messages. This includes fleet management, home automation, real-time telemetry on computer hardware, and practically any use case where sensors generate data points periodically.

Why use InfluxDB for MQTT data?

If you’ve already concluded that the MQTT protocol is the right way to move your data from various devices into a centralized broker, odds are that you’re working with time series data. Time series data has a couple of key characteristics: it’s a sequence of data collected in chronological order, and all data points contain a timestamp. Most commonly, this also means there’s a large volume of data. Hundreds or thousands of sensors generating new data points every second can quickly turn into millions or billions of records per day. As the scale of data increases, the need for a specialized, purpose-built solution to handle this volume grows, too.

That’s where InfluxDB, the industry-leading time series database, comes in. InfluxDB is purpose-built for the time series data common in MQTT use case scenarios, delivering unparalleled performance and a number of dedicated features to make managing and working with your time series data as easy as possible.

Performance is critical because ingesting millions or billions of data points per day can strain most databases. Because time series databases like InfluxDB are optimized to handle that firehose of continuous data, they can scale to handle and ingest it with greater efficiency and lower costs. A custom-built storage engine eliminates snags that most other types of databases encounter, such as index maintenance and contention locks. Last-value caches and engine optimizations for timestamp-based filtering makes retrieving recent data extremely efficient, so fresh data being written into InfluxDB can be queried in less than 10 milliseconds, minimizing time to insight (or as we like to call it, “time to awesome”). This ensures a real-time view of the data generated across your network of devices.

Time series functionality also makes managing and working with this data much easier, regardless of if performance at scale is a concern. DataFusion, the SQL query engine embedded into InfluxDB 3, makes it easy to query with a language most data professionals and AI agents already know. With dedicated time-based functions, queries that look like this in a general purpose database:

WITH hours AS (
  SELECT generate_series(
    date_trunc('hour', now() - interval '24 hours'),
    date_trunc('hour', now()),
    interval '1 hour'
  ) AS hour_bucket
),
sensors AS (
  SELECT DISTINCT sensor_id FROM sensor_data
),
hour_sensor AS (
  SELECT h.hour_bucket, s.sensor_id
  FROM hours h
  CROSS JOIN sensors s
),
agg AS (
  SELECT
    sensor_id,
    date_trunc('hour', time) AS hour_bucket,
    percentile_cont(0.95) WITHIN GROUP (ORDER BY temperature) AS p95
  FROM sensor_data
  WHERE time >= now() - interval '24 hours'
  GROUP BY sensor_id, hour_bucket
)
SELECT
  hs.hour_bucket,
  hs.sensor_id,
  COALESCE(a.p95, 0) AS p95
FROM hour_sensor hs
LEFT JOIN agg a USING (hour_bucket, sensor_id)
ORDER BY hs.sensor_id, hs.hour_bucket;

Can be shortened to this in InfluxDB:

SELECT
  date_bin_gapfill(INTERVAL '1 hour', time) AS hour,
  sensor_id,
  interpolate(percentile(temperature, 95)) AS p95
FROM sensor_data
WHERE time >= NOW() - INTERVAL '24 hours'
GROUP BY hour, sensor_id;

Admittedly, this is a cherry-picked example for a complicated function most users won’t use every day, but there are plenty that aren’t. The InfluxDB 3 processing engine comes with a host of built-in plugins for processing and transforming data as it’s written, monitoring and anomaly detection, forecasting, and alerting. Retention policies can be set at a database or table level, ensuring you keep data as long as it’s useful, and the downsampling plugin for the processing engine can help you keep your data at a lower resolution once it’s past the end of that policy. InfluxDB also has tons of connections to the ecosystem of data visualization tools, clients, and, critical for the purposes of this tutorial, integrates seamlessly with Telegraf, the data collection agent we’ll be using to move data from our MQTT broker into InfluxDB.

The MQTT -> InfluxDB pipeline

The architecture of this data pipeline is relatively straightforward, with data flowing in one direction throughout:

Devices, sensors, and anything generating raw data are set up as an MQTT publishing client connected to the broker.
The MQTT broker receives the raw data from the various publishers and forwards it.
Telegraf subscribes to the published topics and then writes data into InfluxDB.
The InfluxDB processing engine handles all necessary transformations and makes the data immediately available for querying and visualization.

So let’s jump into specifics.

Setting Up the MQTT Broker and Clients

The first thing you’re going to need to do is install the MQTT technology of your choice on every device that’s going to be a publishing client, as well as on the server you want to act as your broker. Eclipse Mosquitto is a common open source option for MQTT that we’ll use in this guide, but any other MQTT client, such as HiveMQ, Paho, MQTTX, MQTT Explorer, or EasyMQTT, will also work great for this tutorial. The exact commands will differ depending on what you’re using, but the concepts will remain the same, as it’s a standardized protocol.

To install Eclipse Mosquitto:

On Linux, run: snap install mosquitto
On Mac: Install Homebrew, then run brew install mosquitto
On Windows: Go to the mosquitto download page and install from there

When you install Mosquitto, the installer will then tell you the exact file path that the configuration file sits in. You’ll want to configure your broker first, and you should set up authentication if you don’t want to allow unauthenticated connections. A lack of authentication can be fine if you’re running everything on a local network where you’re not doing any port forwarding, but it’s not recommended if your devices are communicating over the internet.

There are many different ways to set up authentication with Mosquitto—one of the simplest is creating a password file with the mosquitto-passwd command, but you can read a full list of options on their documentation page for authentication methods. Whatever you settle on, if you decide to use some form of authentication, you’ll need to add the following line to your Mosquitto configuration file.:

allow_anonymous false

There are many other configuration options in the documentation, and what you set and configure will depend on your use case, but some you may want to consider are:

persistence false - Because we’re writing to InfluxDB, we don’t need to persist messages to disk.
log_dest stdout - For setting up, testing, and debugging, outputting logs directly to the terminal makes things easier.

And of course, make sure your listener is configured on the same port for all devices. The default is 1883, but you can change this if desired.

Once you configure your broker, you can set up your publishing clients, and with whatever data you’re measuring, they can publish messages to the broker with the command:

mosquitto_pub -h "host" -t "topic" -m "value"

If you’re running this all on a local network, your host will be localhost; otherwise, it’ll be the address where your broker is running. The value should be whatever you’re measuring and publishing at that moment.

Your topic can be whatever is appropriate to label that value. If you have different devices and different types of measurements for each device, it’s recommended to nest your topics and organize them in a way that makes logical sense. For example, if you have many different devices measuring, say, temperature and velocity, your topic arrangement may look like:

/sensors/vehicles/v1/device1/temp
/sensors/vehicles/v1/device1/velocity
/sensors/vehicles/v1/device2/temp
/sensors/vehicles/v1/device2/velocity

As long as you have a unique topic structure for each type of value being sent, we can parse and sort this into tags and fields with InfluxDB. For further information on setting up MQTT topics, there are plenty of great guides on the matter.

With your clients and broker configured, your clients publishing messages, and your broker receiving and forwarding those messages, you should be all set up for the MQTT portion of this data pipeline.

Installing InfluxDB

The next step is to move your MQTT data into InfluxDB. The first step is to install InfluxDB. You can check out our docs on installing it here, but the simplest and easiest way to get started is to run the install scripts provided by InfluxData with:

curl -O https://www.influxdata.com/d/install_influxdb3.sh \
&& sh install_influxdb3.sh

These should work on every operating system and provide you with some simple options to get started with InfluxDB 3 Core or Enterprise. The installation script should also give you an admin token, which you’ll want to store somewhere safe so you can use it for authentication. If you’d like to further configure your InfluxDB 3 instance, the installation script should tell you where all files and configuration files were installed for further adjusting, though it should run fine out of the box.

If you have Docker installed, you can also install the InfluxDB Explorer UI as part of this process, giving you an easy way to view, manage, and query your InfluxDB 3 instance. You can reach it by navigating to localhost:8888 in your browser, entering host.docker.internal:8181 for the server address, and providing the admin token.

Installing and Configuring Telegraf

With InfluxDB 3 installed and running, the last step to get the data pipeline operational is to install and configure Telegraf to connect our MQTT broker to InfluxDB. Telegraf installation varies by operating system and Linux distribution, so check out the Telegraf documentation on installation to find the right files or command to run.

If you’re on Mac or Linux, this will generate a default configuration file for you:

On Mac, install via Homebrew: /usr/local/etc/telegraf.conf
On Linux: /etc/telegraf/telegraf.conf

Otherwise, you’ll need to create an empty configuration file or generate one with telegraf config > telegraf.conf. Once you have located or created your configuration file, all that’s left to do is connect Telegraf to your MQTT Broker and InfluxDB.

InfluxDB is very easy to configure a connection to, and you can add these lines to the config file:

[[outputs.influxdb_v2]]
  urls = ["InfluxDB address & port"]
  token = "admin token"
  organization = "org name"
  bucket = "destination database"

The InfluxDB address and port should be wherever you have InfluxDB installed. If you’re running on a local network, this will be http://127.0.0.1:8181; otherwise, it’ll be the IP and port.
Token is the admin token you copied from installation.
Organization can be whatever you’d like to name it.
Bucket should be the name of the database you’re writing all your MQTT data to. You don’t have to create the database first.

Setting up a connection to your MQTT broker is also straightforward:

[[inputs.mqtt_consumer]]
  servers = ["broker address"]
  topics = ["list of topics"]
  data_format = "value"
  data_type = "data_type"

  ## if you have username and password authentication for MQTT
  username = "username"
  password = "password"

The broker address is one again the address and port for where your MQTT broker is running. For a local network, this will be tcp://127.0.0.1:1883
Topics is a comma-separated list of topics that you’re writing to.
Data type is the primitive data type being written: integer, float, long, string, or boolean.

This is all you need in your configuration file to have the full pipeline running! If you run telegraf with telegraf --config telegraf.conf, you should be able to send a message from an MQTT publisher and view that data in InfluxDB.

However, you can make some improvements in Telegraf’s configuration to help parse and organize your data by topic. By default, this writes each topic into a single tag column to the same table, with a monolithic “value” column for all your values, which isn’t a very good data model. With topic parsing and pivot processing added to the configuration, we can specify what part of the topic should define what table the data is written into, turn every level of the topic into a tag, and pivot on the last level of the topic so that each raw value is its own field:

[[inputs.mqtt_consumer]]
  servers = ["broker address"]
  topics = ["/sensors/#"]
  data_format = "value"
  data_type = "data_type"

  ## if you have username and password authentication for MQTT
  username = "username"
  password = "password"

  [[inputs.mqtt_consumer.topic_parsing]]
    measurement = "/measurement/_/_/_/_"
    tags = "/_/device_type/version/device_name/field"
  [[processors.pivot]]
    tag_key = "field"
    value_key = "value"

This takes a value from the /sensors/vehicles/v1/device1/temp topic and writes it to the sensors table. The tag columns populate with device_type = vehicles, version = v1, device_name = device1, and temp is written as a field with the value of temp set to whatever your MQTT publisher wrote. You can modify this configuration as appropriate for your topics, and the documentation provides full information on everything that can be done.

Further improvements

With MQTT data being published, parsed, and written into InfluxDB, you’ve fully set up an MQTT data pipeline! However, there’s a lot more you can do:

View and query your data with the InfluxDB Explorer UI, as discussed earlier.
Connect any one of the many client libraries to access your data and use it for downstream applications, or to a data visualization tool for dashboarding and insight into what’s being written.
Use the InfluxDB 3 processing engine for further transformations and processing of your data as it’s written.
Set up alerts, monitoring, forecasting, and more with the processing engine, too.

The final product

By integrating MQTT, Telegraf, and InfluxDB, you’ve constructed a robust, fully-functioning data pipeline capable of efficiently centralizing real-time telemetry. The lightweight MQTT protocol ensures that messages from your distributed network flow reliably to the broker, while Telegraf acts as the collection agent for seamless ingestion and transformation. Finally, InfluxDB provides the purpose-built storage and specialized features needed to query and visualize your data in minimal time. This architecture establishes a solid foundation for turning raw event streams into meaningful insights, minimizing your time to awesome.

From Edge to Cloud: How Litmus Edge and InfluxDB Unlock Industrial Intelligence at Hannover Messe

Ben Corbett (InfluxData) — Thu, 16 Apr 2026 06:00:00 +0000

If you’ve spent time in industrial environments, you know the problem isn’t a lack of data. It’s collecting it reliably, contextualizing it, and storing it at scale. Most stacks weren’t built to fight all three battles.

The industrial data problem

Industrial connectivity is no joke. OT environments are notoriously fragmented and siloed, spanning PLCs, CNCs, SCADA systems, and sensors, each speaking a different protocol, running on a different vendor’s stack, and operating in a network zone that was never designed to talk to anything outside the shop floor. Extracting value from that data has traditionally required heavy IT involvement, expensive integrations, and months of professional services work, and the traditional answer was usually a historian. Historians made progress on the access problem, giving individual sites a way to capture and store machine data. But standardizing that data across silos and contextualizing it across systems and plants is where they fall short. And unfortunately, that’s where most of the value lies.

Once data is collected and contextualized, the next problem is keeping it useful at scale. This is more than a storage problem. Sustaining high-frequency ingest of contextualized telemetry and querying that data fast enough to act on it is where most systems break. Historians were not designed for this. They sacrifice resolution, degrade under query load, and make cross-site, cross-system analysis slow and impractical. The value in industrial data is in the detail, and most platforms are architected to throw this detail away.

Collect, contextualize, and store—all at the edge

Litmus Edge acts as the intelligence layer between your machines and the rest of your data architecture. It connects natively to hundreds of industrial protocols, including OPC-UA, Modbus, MQTT, FANUC, Siemens S7, and many more, normalizing disparate machine data into a unified, consistent stream.

But connectivity alone isn’t enough. Raw machine signals mean little without context. Litmus Edge allows operations teams to tag, enrich, and structure data at the point of collection. A temperature reading becomes tied to a specific asset, production line, facility, and product run. By the time data leaves the edge, it is no longer just a number. It is a meaningful, queryable event.

Scale, query, retain: your industrial data hub

InfluxDB 3 becomes the system of record for your industrial time series data at the edge, in a centralized environment, or both.

It ingests high-frequency telemetry at full resolution, serves low-latency queries for real-time operations, and scales to fleet-wide analysis across sites and time horizons without forcing tradeoffs between fidelity and cost. High cardinality isn’t a problem to design around. Long-term retention doesn’t require a cost penalty. The data stays detailed, queryable, and useful.

Scaling across lines, sites, and the enterprise

Scale changes what’s possible, but only if the data model scales with it. When every site collects and contextualizes data the same way, writing to a consistent schema, cross-site analysis becomes straightforward. Comparing performance across plants, identifying outliers, and correlating signals across a global fleet become simple queries instead of integration projects. That consistency is what the Litmus and InfluxDB architecture is designed to deliver.

Which production lines across all facilities are showing early indicators of equipment degradation?
How does energy consumption per unit compare across sites running similar processes?
Where are the outliers? And what can the top performers teach the rest of the network?

These are not hypothetical future capabilities. They are available today to any organization willing to invest in getting the data foundation right.

The bridge to higher-level analytics

InfluxDB doesn’t just store data well; it integrates cleanly with the ecosystem: the analytics, visualization, and AI/ML tooling your teams are already investing in. Grafana dashboards, anomaly detection workflows, and digital twin platforms connect through InfluxDB’s SQL-native interface and open APIs without custom pipelines or bespoke integration work.

For OT teams, that’s the point. The edge handles the hard part—protocol translation, normalization, enrichment. InfluxDB centralizes the results into a single, interoperable data layer that every team can query with the tools they already use.

The result is a data architecture that is genuinely interoperable; the plant floor and the enterprise layer are finally speaking the same language.

Extending into the cloud with AWS

There are several ways to deploy InfluxDB as your industrial data hub: on-premises, at the edge, or in the cloud. For teams who want to go straight to the cloud, AWS is a natural fit. In this reference architecture, Litmus Edge writes contextualized telemetry directly into Amazon Timestream for InfluxDB, creating a seamless path from the shop floor to cloud-scale analytics. This allows teams to centralize access, scale analytics, and integrate with the broader AWS ecosystem without rebuilding their infrastructure from scratch.

Once data is available in AWS, it opens up a broader set of capabilities. For example, as new data arrives, you can trigger serverless workflows with AWS Lambda, stream high-velocity data through Kinesis for downstream processing, or connect directly to SageMaker to train models on high-fidelity data, without reshaping or downsampling it first.

What we’re showing at Hannover Messe

At Hannover Messe, you’ll be able to see this architecture running end-to-end:

Litmus booth (Hall 16, Stand A09): The full Digital Factory demo, showing how data flows from industrial systems into Litmus and into InfluxDB 3 Enterprise in real-time.
InfluxData kiosk (within the Litmus booth): A deeper look at how InfluxDB handles high-frequency ingest, real-time querying, and efficient storage at massive scale.
AWS booth (Litmus kiosk): The cloud extension of the demo, highlighting replication into Amazon Timestream for InfluxDB and integration with AWS services.

The InfluxData team (including myself) will be on-site at the Litmus booth throughout the event to walk through the architecture and discuss real-world deployment patterns.

Post by Ben Corbett, InfluxData; Rajesh Gomatam, Ph.D. Principal Partner Solutions Architect - Manufacturing, AWS; and Benjamin Norman, Partner Solution Architect, Litmus

What’s New in InfluxDB 3 Explorer 1.7: Table Management, Data Import, Transforms, and More

Daniel Campbell (InfluxData) — Wed, 15 Apr 2026 05:30:00 +0000

InfluxDB 3 Explorer 1.7 is a step forward for anyone who wants to manage their time series data without constantly switching between the UI and a terminal. This release adds table-level schema management, the ability to import data from other InfluxDB instances, and a new Transform Data section to reshape your data, all within the Explorer UI.

Table management

Previously, if you wanted to see what tables existed inside a database, you had to query system tables or use the API. The new Manage Tables page changes that. You can get there from the sidebar or from the new actions menu on any database in the Manage Databases page. That actions menu gives you quick access to query a database, view its tables, or delete it.

The Manage Tables page lists every table in the selected database, along with its column count, type, and any configured Distinct Value or Last Value Caches. Use the toggle filters to show or hide system tables and deleted tables. Deleted tables show up with a “Pending Delete” badge when the Show Deleted Tables toggle is enabled, so you always have visibility into what’s been removed.

You can also create new tables directly from this page. The Create Table dialog lets you define the schema up front: name, fields with data types, optional tags, and a retention period. This is useful when you want to control your schema explicitly rather than relying on schema-on-write to infer types from the first arriving data points.

From any table’s action menu, you can jump straight to the Data Explorer with a pre-built query for that table.

Import from InfluxDB

The next few features I’ll discuss are enhancements that make it much easier to work with the InfluxDB 3 Processing Engine.

Moving data between InfluxDB instances used to mean writing scripts, dealing with export formats, and coordinating tokens across environments. The new Import from InfluxDB feature provides a guided workflow for migrating small-to-medium datasets from any existing InfluxDB v1, v2, or v3 instance (assuming v3 Schema compatibility) into your current InfluxDB 3 database.

You’ll find it under the Write Data section, on both the Dev Data and Production Data pages. The workflow walks you through selecting a target database (or creating a new one), connecting to a source InfluxDB instance, authenticating, and then choosing which databases and tables to import.

Before committing to the import, perform a dry run that shows you exactly what will be transferred, including the source and destination, the number of tables, the estimated row count, and how long it should take. Advanced options let you tune the batch size and concurrency if you need to balance import speed against resource usage.

Once you start the import, a live progress view shows you how far along things are, how many rows have been imported, and the current status of each table. When it finishes, a “Query this database” button takes you straight to the Data Explorer so you can verify everything landed correctly.

If you’re running an InfluxDB 1.x or 2.x instance and want to try InfluxDB 3 with your real data, this saves you from building a migration pipeline. Just point the import tool at your existing instance, pick the databases and time range you want, and the data flows over. It also works for consolidating data from multiple InfluxDB 3 instances into one place, or pulling production data into a dev environment for testing.

Transform data

The new Transform Data section in the sidebar gives you a visual interface for setting up data transformations that run automatically on ingestion via the Processing Engine. Under the hood, these are powered by the Basic Transformation Processing Engine plugin, but you don’t need to write any plugin configuration by hand. The UI handles that for you.

The way it works: when data is written to a source table, the transformation runs automatically and writes the results to a target database or table. You can set a short retention period on the source data (say, one day) so the raw data cleans itself up, and the transformed data lives on in the destination. There are four types of transformations available.

Rename Table

Rename Table lets you route data arriving in one table to another table. This is handy when you’re consuming data from a source you don’t control, and the table names don’t match your naming conventions.

Rename Columns

Rename Columns works similarly, but at the column level. You pick a source table and select which columns to rename. If you’re integrating data from different systems that use different naming conventions (for example, temp_f vs temperature_fahrenheit), this standardizes everything without touching the source.

Transform Values

Transform Values lets you apply calculations or conversions to field values as they come in. You can do math operations, string transformations, unit conversions, or simple find-and-replace. If your sensors report temperature in Celsius but your dashboards expect Fahrenheit, this handles the conversion at ingestion time so your queries stay clean.

Filter Data

Filter Data lets you keep only the rows or columns that match specific conditions. You can filter by rows (e.g., only keep data where crop_type = 'carrots') or by columns (drop fields you don’t need). This is useful when you’re receiving more data than you actually want to store. For example, a third-party feed might send 50 fields when you only care about 5.

You can test each transformation before deployment, and once deployed, monitor its status (running, stopped, errors) from the Transform Data dashboard.

Downsample Data

Downsampling is a classic time series operation: take high-frequency data and roll it up into lower-frequency summaries to save storage and speed up queries over long time ranges. The new Downsample page, also under the Transform Data section, makes this easy to set up. You create a downsample trigger by specifying a source table, a target table, a schedule (how often the aggregation runs), a time window (how far back to look), an aggregation interval (the bucket size), and an aggregation function (avg, sum, min, max, etc.). You can also choose to include or exclude specific fields.

The Downsample Processing Engine plugin powers this feature.

Get started

All of these features are available now in InfluxDB 3 Explorer 1.7. For more on these Processing Engine capabilities, see InfluxDB 3 Processing Engine Updates.

If you’re running InfluxDB 3 Core or Enterprise, update to the latest version to try them out. To learn more, check out the InfluxDB 3 Explorer documentation.

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

Less Friction, More Control: Here's What Shipped in Q1

Ryan Nelson (InfluxData) — Wed, 08 Apr 2026 08:00:00 +0000

Our Q1 momentum has been focused on a simple goal: making InfluxDB easier to operate, easier to scale, and faster to put to work.

Across Telegraf, InfluxDB 3, and our managed offerings, these updates reduce friction in how teams collect, process, and scale time series workloads.

Telegraf Controller enters beta

Telegraf is already a powerful way to collect metrics, logs, and events across environments. At scale, the challenge shifts from collection to control. Telegraf Enterprise is designed to solve that problem.

At the center is Telegraf Controller, a control plane that gives teams centralized configuration management and fleet-wide health visibility. The beta includes major capabilities such as API authentication, API token management, user account management, multi-user support, role-based access control, global settings management, and expanded plugin support in the visual config builder.

Feedback from early users is shaping the road to general availability, with enterprise licensing, enforcement, audit logging, and federated identity management next on the roadmap. Sign up to join the beta.

InfluxDB 3.9 adds more operational control

Last week’s release of InfluxDB 3.9 is focused on making the platform easier to run at scale, with improvements aimed at predictability, visibility, and day-to-day management. The release expands CLI and automation support for headless environments, improves resource and lifecycle management, and adds clearer visibility into access control and product identity across Core and Enterprise deployments. These are the changes that matter in production: fewer rough edges, stronger operational clarity, and better control as workloads grow.

InfluxDB 3.9 Enterprise also includes a new beta performance preview for non-production environments. This optional preview includes optimized single-series queries, reduced CPU and memory spikes under load, support for wider and sparser schemas, and early automatic distinct value caches to reduce metadata query latency. These features are not yet recommended for production, but they give customers an early look at capabilities planned for future releases and a chance to help shape what comes next.

Processing Engine updates make InfluxDB 3 easier to operationalize

The Processing Engine remains one of the most powerful parts of InfluxDB 3 because it allows teams to run logic directly at the database. Users can transform data on ingest, run scheduled jobs, or serve HTTP requests without adding external services or layering on more pipeline complexity.

This quarter, we continued to expand both the engine itself and the plugin ecosystem around it. The latest plugins make it easier to get data into InfluxDB 3 from more sources:

The Import Plugin provides a simpler path for bringing data from InfluxDB v1, v2, or v3 into InfluxDB 3 Core and Enterprise, with support for dry runs, progress tracking, pause and resume, conflict handling, and flexible filtering.
New MQTT, Kafka, and AMQP subscription plugins help users ingest streaming data directly from external message brokers.
The new OPC UA Plugin gives industrial teams a more direct path to data from PLCs, SCADA systems, and other OPC UA-enabled equipment.

We also made important improvements to the Processing Engine itself:

New synchronous write controls give plugin authors more flexibility over durability and throughput.
Batch write support improves efficiency for high-volume workloads.
Asynchronous request handling keeps status checks and control operations responsive during long-running jobs.

Together, these updates make the Processing Engine a more practical way to build and operate real-time data pipelines directly inside InfluxDB 3. Check out our docs to learn more.

Better visibility for Cloud Dedicated customers

As teams run production workloads on Cloud Dedicated, understanding how the system is being used becomes just as important as performance itself.

This quarter, we introduced:

Query History (GA) for troubleshooting, performance analysis, and deeper insight into query activity.
S3 API dashboards (Tier 1 and Tier 2), including monthly usage visibility.

These updates give teams better visibility into system behavior, usage patterns, and a faster path to understanding activity across the environment. Detailed docs here.

InfluxDB Enterprise 1.12.3 delivers efficiency gains for v1 environments

For teams needing more performance and running large-scale v1 Enterprise environments, InfluxDB Enterprise 1.12.3 is now available with substantial improvements in efficiency and reliability:

100x faster retention enforcement for high-cardinality datasets
30% lower CPU usage during compaction
5x faster backups with configurable compression
3x less disk I/O during cold shard compactions

These improvements make Enterprise v1 clusters more efficient, more predictable under load, and more cost-effective to operate. Read the release notes.

Amazon Timestream for InfluxDB adds a new scale tier and simple upgrade path

InfluxDB 3 on Amazon Timestream for InfluxDB now supports clusters of up to 15 nodes, giving customers a new scale tier for more demanding real-time workloads.

This expanded tier improves query concurrency, increases ingestion throughput, and provides stronger workload isolation across ingestion, queries, and compaction. For teams running high-velocity, high-resolution data in production, that means more headroom to scale without compromising real-time performance.

Customers can also seamlessly migrate from InfluxDB 3 Core to InfluxDB 3 Enterprise, making it easier to move into this higher-performance tier without a manual architectural overhaul or data loss. The new 15-node option is available for InfluxDB 3 Enterprise in all AWS regions where Amazon Timestream for InfluxDB is offered. Read more here.

Looking ahead

Taken together, these updates are about helping teams do more with less friction: move data faster, operate with more confidence, and scale time series workloads without losing control. As operational data becomes more central to modern systems, we are continuing to invest in the infrastructure that turns that data into action across edge, cloud, and distributed environments.

InfluxData Blog

What’s New in InfluxDB 3.10: Performance Beta Expanded with New Enterprise Features

Expanded capabilities for the performance beta

User authentication and RBAC preview

General updates and improvements

Cross-Database Plugin Queries

Readiness Endpoint

Improved Compaction

Get started with InfluxDB 3.10

Generate Synthetic Time Series Data in InfluxDB 3

Why generate sample data this way?

Bird Tracking Simulator

Signal Generator

Lightweight data generation for InfluxDB 3

Satellite Telemetry, ITAR, and Data Residency: Building Architecture for Speed and Control

Why ITAR and data residency matter for telemetry

Data Movement Creates the Control Challenge

What data sprawl costs mission teams

How InfluxDB 3 supports controlled telemetry monitoring

How the Architecture Works

Deployment Flexibility for Sensitive Data

Eutelsat OneWeb: Satellite Telemetry at Scale

The bottom line

Building a Predictive Maintenance Plugin with the InfluxDB 3 Processing Engine

What we’re building

Prerequisites

Install InfluxDB 3 Core

Docker

Start InfluxDB with the Processing Engine enabled

Create an admin token

Create a database

Load the dataset into InfluxDB

An overview of the plugin model

Predictive maintenance plugin logic

Creating the plugin

Creating the trigger

Testing out the plugin

Inspecting logs and iterating

Error Handling

What to build next

Anomaly Detection and Forecasting That Learns From Every Write in InfluxDB

River Anomaly Detector: multiple ways to detect problematic data

River Auto-Profiler: the control plane for per-series tuning

River Forecaster: short-horizon forecasts from the write stream

Using the River plugins with InfluxDB

6 Signs Your Historian Renewal Should Be a Modernization Conversation

Sign 1: Your renewal quote is higher, and so is your tag count

Sign 2: Your data science team is still waiting for that export

Sign 3: A new workload just got bounced back to you

Sign 4: Every plant is an island

Sign 5: The platform is a closed system, and that’s becoming a problem

Sign 6: “Historian limitations” shows up in every initiative’s risk log

What to do about it, before signing a contract

InfluxDB 3 MCP Server v1.3.0: AI Access to Time Series Data

TL;DR

What is the InfluxDB 3 MCP server?

What’s new in v1.3.0?

How do I install the MCP Server for InfluxDB 3 Core?

Other MCP Clients

How do I install the MCP Server for InfluxDB 3 Enterprise?

Cloud Variants

Try it against a real running system

Links

A Runnable Reference Architecture for Industrial IoT on InfluxDB 3

What is the InfluxDB 3 IIoT reference architecture?

What’s in the stack

The features it’s actually showing you

1. The Processing Engine – Python plugins running inside the database

2. Last Value Cache – single-digit-millisecond current state

3. Distinct Value Cache – fast cardinality on high-cardinality tags

When to bring in OPC UA: the Processing Engine plugin

How to drop the IIoT architecture into your environment

Try it yourself

Resources

A Runnable Reference Architecture for Network Telemetry on InfluxDB 3

What is the network telemetry reference architecture?

What’s in the stack

The features it’s actually showing you

1. A real multi-node cluster, with role-separated nodes

2. The Processing Engine – Python plugins in a multi-node cluster