InfluxData Blog

Building a Practical Time Series Data Layer for Automotive Manufacturing

Cole Bowden (InfluxData) — Wed, 09 Sep 2026 08:00:00 +0000

Automotive manufacturing generates data at several operating cadences. Sensors and controllers emit measurements continuously. Equipment and line states change as events. Production and quality systems add context at the part, batch, shift, and plant level. Together, these records describe how a manufacturing process behaves over time.

That data can support plant visibility, investigations, scrap reduction, condition monitoring, and longer-term comparison, but only if the storage and query layer can keep up with the workload. InfluxDB is a practical fit for these types of workloads because it is optimized for continuous, time-stamped data and can process, retain, and query it without requiring every system around it to be redesigned.

Why automotive data is a time series workload

A time series workload is, at its core, any data where you primarily store, query, and analyze it by looking at when it happened and how it progressed from one state to another.

A temperature measurement in a time series workload never exists in isolation. When a device overheats, you ask how long it took to heat up, whether it had opportunities to cool down, and what that looked like over the span of five, ten, or fifty minutes. The same principles can apply to vibration, torque, current, pressure, flow, cycle state, machine availability, inspection results, alarms, and many other signals generated during vehicle and component production.

Queries are written to understand what changed during a particular interval, whether a condition persisted, how one shift compared with another, or how several signals behaved around a production or quality event. Those queries tend to start with a filter on timestamps to the relevant window in which questions are being asked, narrow the data to the relevant equipment or process, and then aggregate, compare, or retrieve the latest values.

The write pattern of time series data is often distinctive, too. Sensors create readings at a regular cadence, so new data points arrive continuously, almost exclusively as appends to the database, with few or no updates or edits to historical rows.

The same data also has value at very different time scales. Recent, high-resolution telemetry can support detailed investigations. Longer-range summaries can support plant management, capacity planning, process comparison, forecasting, and cross-plant visibility. Keeping every full-resolution observation may be difficult to justify, but reducing everything to hourly averages at ingestion time throws away information before anyone knows whether it will matter.

This combination of continuous writes, time-bounded reads, multiple resolutions, and changing retention value is what makes automotive telemetry a time series workload.

Automotive systems also contain plenty of data that doesn’t fit this description. Bills of material, work orders, user accounts, inventory records, and transactional production data may belong in an MES, ERP system, or relational database. InfluxDB is designed to operationalize telemetry, and it’s part of a well-orchestrated tech stack.

Why use a time series database?

Any relational database (or even Excel) can store time-stamped measurements. The question is: how efficiently, effectively, and easily can they handle a time series workload, and can they scale? We already have a blog on this topic that explains the advantages of time series databases, and it’s a good place to start if you want to understand their key advantages.

To summarize for automotive telemetry: InfluxDB most efficiently handles high-volume ingestion and time-oriented querying, while database- and table-level retention lets you control how long each data type remains available. A high-volume raw table can have a shorter retention period than a cleaned or downsampled table in the same database, and because InfluxDB 3 is designed and built for low-cost object storage, data costs stay low. Even better, all tables are very efficiently compressed, minimizing the footprint in object storage and lowering costs.

The Last Value Cache addresses another common query pattern: retrieving the newest value, or last few values, for each series. That is useful for current-state views where repeatedly scanning recent history would be unnecessary work.

These features map directly to the shape of automotive manufacturing data workloads, which ingest continuously, query by time, keep recent detail, summarize older data, and serve current state efficiently. This makes a time-series database like InfluxDB the only cost-effective, performant, scalable choice for high-volume, time series workloads.

A reference architecture for automotive manufacturing

Rather than talking about it at a high level, it may be easier to show you how the architecture works in action.

The InfluxDB 3 automotive manufacturing reference architecture is a runnable example of an automotive time series pipeline. It uses Docker Compose, InfluxDB 3 Enterprise, Processing Engine plugins, and a small web UI:

git clone https://github.com/influxdata/influxdb3-ref-auto-manufacturing.git
cd influxdb3-ref-auto-manufacturing
make up

On first boot, the setup asks for an email address and sends an InfluxDB 3 Enterprise license-validation link. After validation, this stack begins generating and processing the simulated plant data, and you can see it by opening the UI at:

http://localhost:8080

The repository installs InfluxDB-approved plugins, creates tables and triggers, runs the processing chain, and exposes raw, processed, downsampled, and forecast data through the UI. It also demonstrates isolated station pipelines and a Last Value Cache for current-state views.

Make sure you read the production notes before using it as a deployment template. The demo is single-node, uses a file-backed object store, shares an admin token between services, and does not enable TLS inside the Compose network. Production requires scoped service tokens, TLS, durable object storage, monitoring, backup planning, and an appropriate multi-node topology. One easy-to-miss detail: create source tables before registering WAL triggers, or the triggers may never fire.

The repository’s most useful pattern is its separation of concerns. You can replace the signal generator with an OPC UA, historian, or gateway feed and keep the downstream stages. You can change the filter without rewriting the dashboard, or you can change retention without touching the PLC.

Building on the reference architecture

Obviously, this is a reference architecture, and it’s meant to be the first step towards building the architecture for your deployment. The most obvious first change to make is replacing the signal generator with an actual data source.

The repository is deliberately structured so that this happens at the input boundary. Telegraf’s OPC UA input can collect data from an OPC UA server and write it to InfluxDB. An industrial integration platform such as Litmus or HighByte can write line protocol through the InfluxDB write API. A historian or existing plant application can also become the source if it already exposes the required data. Downstream processing stages don’t need to know which route the points took to get there.

From there, the work becomes signal-specific.

A regular time grid may be necessary when several sensors need to be aligned or when an algorithm expects a stable sample rate. It may add little value for an event stream. Gap filling should be bounded and explicit, and ideally preserve enough metadata to distinguish observed values from generated ones. Some gaps should remain gaps because the absence of data is useful information, as it can indicate that certain systems were paused or sensors stopped generating readings.

Filtering requires similar care. A filter that cleans up a slowly changing booth-temperature signal may be inappropriate for current, vibration, pressure, or torque. Before filtering a production stream, test the filter against the events engineers actually need to preserve. Keep the raw signal long enough to compare the processed output against it.

Downsampling is another place to be deliberate. Whether you use an average, minimum, maximum, or median, downsampling necessarily entails losing some information. Fortunately, the Downsampler plugin can generate several calculations for the same source measurement. Useful output might include an average for long-term trends, a maximum for threshold analysis, and a count to show whether the interval contained the expected number of observations.

Retention follows the same logic. Raw telemetry can remain available for the period in which detailed investigations are likely. Intermediate processing tables may only need to exist long enough to support the next stage. Cleaned or downsampled data can remain available for longer-range analysis. InfluxDB’s table-level retention overrides make it possible to apply those policies within the same database, so that data can flow from maximal-resolution fresh tables into lower-resolution longer-term storage. This ensures all data is available when needed, without paying to store immense volumes of data that will only be used for sporadic historical analysis.

Finally, the local deployment needs ordinary production hardening. The repository’s architecture notes cover moving from local files to S3, Google Cloud Storage, or Azure Blob Storage; separating ingest, query, compaction, and processing roles; using scoped tokens for individual services; and enabling TLS across trust boundaries. Plugins should also have version control, automated tests, resource limits, and a repeatable deployment process. Running Python inside the database removes some infrastructure, but it’s still production code.

Augmenting an existing automotive data stack

Many automotive environments already have control systems, historians, manufacturing applications, quality systems, and enterprise analytics infrastructure. There’s no need to displace them before evaluating InfluxDB. Similarly, the justification for adding InfluxDB doesn’t depend on proving that the historian, warehouse, or relational database is bad. It depends on whether a specialized time series database can serve a particular workload more efficiently.

A useful entry point is to start bounded, picking a specific task or domain where InfluxDB may be worth leveraging. Mirror data from that domain into InfluxDB, but allow your existing systems to remain authoritative. Because InfluxDB 3 uses SQL, you can likely run the same queries across your existing system and InfluxDB at the same time, and just like that, you’re testing which system is more efficient. How fresh is the data? What’s the query latency, especially when you’re leveraging the Last Value Cache?

Once it’s running, you can see what else InfluxDB unlocks for you. Use the Processing Engine with ML plugins to detect anomalies and generate forecasts that help with predictive maintenance. Hook into the InfluxDB MCP server to power your AI agents with your data. The database is the backbone, and what you build on top of it is where you truly begin to derive value.

Measure sustained ingestion, storage consumption at each resolution, query latency for real investigation patterns, and operational overhead. Ask yourself how useful the resulting analysis, forecasts, and downstream tools you built are. A bounded evaluation with representative data gives you evidence from your own workload, which is what truly matters for your use case.

Bringing it all together

Automotive telemetry has the defining characteristics of a time series workload: continuous writes, time-bounded queries, value at multiple resolutions, and a useful lifetime that changes as the data ages.

InfluxDB provides a specialized solution for that workload. The automotive reference architecture makes the design concrete by showing how ingestion, resampling, gap filling, filtering, downsampling, forecasting, caching, and retention can fit together without becoming one inseparable pipeline. Once you’ve got the data flowing, you’ll unlock new capabilities to maximize the value you get from your data, driving efficiency and better data-driven results.

Get started with a free trial of InfluxDB 3 Enterprise, and try it out today.

Getting Started with InfluxDB 3 and Grafana Tutorial

Charles Mahler (InfluxData) — Wed, 02 Sep 2026 07:00:00 +0000

InfluxDB and Grafana are the most common pairing in time series monitoring, and division of labor between them is simple. InfluxDB stores and queries the data: high-volume, time-stamped readings from sensors, servers, meters, vehicles, and anything else that emits time series. Grafana visualizes the data: dashboards, time series panels, stat tiles, state timelines, and alerts. Neither tool replaces the other, and many production monitoring stacks run both.

Connecting them has gotten considerably simpler with InfluxDB 3. Grafana ships with a built-in InfluxDB datasource that speaks InfluxDB 3 SQL over Flight SQL, so there is no third-party plugin to install and no custom query language to learn.

This guide walks through that integration end-to-end using a realistic dataset you generate yourself. You will learn the following in this tutorial:

Getting data in - Writing line protocol and what tags, fields, and timestamps mean for how you will query later.
Transforming data as it arrives - Using an InfluxDB 3 Python Processing Engine plugin to turn raw readings into a derived table of decisions. This pattern keeps dashboard queries simple and your source data untouched.
Connecting Grafana securely - Read-only tokens and the datasource settings that actually matter.
Building a real dashboard - Template variables, chained variables, $__timeFilter, date_bin() for downsampling, and eight panels across stats, time series, state timelines, bar gauges, and tables.

What you will build with InfluxDB 3 and Grafana

To make all of that concrete, you will generate a week of smart-building data. The generator is deterministic, so your numbers will match the expected output at every step, and you can verify each stage rather than guessing.

The raw table, building_telemetry, preserves the original readings. The derived table, iaq_assessment, adds an indoor-air-quality risk score, a severity label, a recommended action, and a conservative estimate of energy used above an idle baseline. The finished dashboard answers four questions an operator actually asks:

Which occupied rooms experienced unhealthy air?
Where did CO₂ and PM2.5 spike?
How much energy was consumed while rooms were empty?
Which building zones should someone investigate first?

The dataset has four incidents deliberately built into it. A stuffy Tuesday conference room, a lab drawing power on an empty Wednesday evening, a Thursday ventilation problem in the design studio, and a building-wide Friday particulate event, so every panel has something real to show.

Buildings are just an example. The architecture in this tutorial applies unchanged to industrial equipment, fleet telemetry, energy metering, network devices, or application metrics. If you are evaluating InfluxDB and Grafana for any of those, this is a working template.

Prerequisites

This walk-through assumes:

A Debian- or Ubuntu-based Linux environment; Grafana also publishes installation instructions for RHEL, Fedora, and other supported systems.
Python 3.9 (or newer).
sudo access for installing Grafana.
An InfluxDB 3 Enterprise trial, at-home, or commercial license.

Why use Grafana’s built-in InfluxDB datasource?

Grafana includes an InfluxDB datasource that supports InfluxDB 3 SQL out of the box. There’s no need to install anything else, which makes getting started easy.

Other choices still have valid uses:

InfluxQL is supported by the plugin as well, and is useful when migrating existing InfluxDB 1.x queries or working through an HTTP/1.1-only proxy.
A separately hosted Grafana is useful for a shared observability platform, but its backend needs private, HTTP/2-capable access to the InfluxDB query node.
A custom API can add domain-specific authorization or reshape data, but it adds another service that a beginner tutorial does not need.

Create Your Project Directory

Create a folder anywhere convenient and open it in your text editor:

mkdir smart-building-demo
cd smart-building-demo
mkdir plugins influxdb-data

The tutorial uses only these local paths:

smart-building-demo/
├── generate.py
├── smart-building.lp
├── influxdb-data/
└── plugins/
    └── iaq_assessment.py

Keep the terminal in smart-building-demo for the remaining commands.

Install and Start InfluxDB 3 Enterprise

InfluxData provides a quick installer for Linux and macOS. Download the installer first so you can inspect it before running:

curl -o /tmp/install_influxdb3.sh \
  https://www.influxdata.com/d/install_influxdb3.sh

# Optional: inspect the downloaded script before running it.
less /tmp/install_influxdb3.sh

sh /tmp/install_influxdb3.sh enterprise

The installer tracks the latest InfluxDB 3 Enterprise release. For production, InfluxData recommends its DEB/RPM packages or a carefully secured container deployment; see the official installation guide.

Verify that the binary is available:

influxdb3 --version

If the command is not found, open a new terminal or follow the installer’s instructions for adding the binary to your PATH, then return to the demo directory.

Start the Database with the Processing Engine Enabled

Run InfluxDB in the first terminal and leave it running:

influxdb3 serve \
  --node-id smart-building-node \
  --cluster-id smart-building-cluster \
  --object-store file \
  --data-dir "$PWD/influxdb-data" \
  --plugin-dir "$PWD/plugins"

The --plugin-dir flag activates the Processing Engine and tells InfluxDB where to find the Python file you will create. The data directory persists the database between restarts. These options are documented in the Processing Engine guide.

On the first start, InfluxDB asks you to choose and activate a license. A trial provides full Enterprise features for 30 days; the at-home license is intended for eligible hobbyist use. Follow the prompts and email-verification step described in the license documentation. Do not include license files, license JWTs, or account details in screenshots or source code.

Create and Store the Administrator Token

Open a second terminal, return to smart-building-demo, and create the initial administrator token:

influxdb3 create token --admin

InfluxDB displays this token only once. Store it in a password manager. Then load it into the current terminal without placing it in shell history:

read -rsp "Paste the InfluxDB administrator token: " INFLUXDB_TOKEN
echo
export INFLUXDB3_AUTH_TOKEN="$INFLUXDB_TOKEN"
export INFLUXDB3_HOST_URL="http://127.0.0.1:8181"

Do not put the token in generate.py, the plugin, Grafana queries, screenshots, or a committed shell script. InfluxDB’s authorization setup guide recommends the INFLUXDB3_AUTH_TOKEN environment variable for CLI authentication.

Create a database for the demo:

export INFLUXDB_DATABASE="smart_building"
influxdb3 create database "$INFLUXDB_DATABASE"

Expected result: the command completes without an error. You can confirm the database exists with:

influxdb3 show databases

Generate a Demo Telemetry Data

A good tutorial dataset should be small, understandable, and repeatable. This generator creates six zones, sampled every five minutes for seven days.

In your editor, create generate.py in smart-building-demo and paste the following code:

#!/usr/bin/env python3
"""Generate deterministic smart-building telemetry as InfluxDB line protocol."""

from __future__ import annotations

from datetime import datetime, timedelta, timezone
import math
from pathlib import Path
import random

START = datetime(2026, 8, 10, tzinfo=timezone.utc)
INTERVAL = timedelta(minutes=5)
POINTS_PER_ZONE = 7 * 24 * 12

ZONES = [
    {"building": "hq", "floor": "1", "zone": "open_office", "sensor": "hq-1-open", "capacity": 40, "offset": 0.0},
    {"building": "hq", "floor": "1", "zone": "conference_a", "sensor": "hq-1-conf-a", "capacity": 12, "offset": 0.3},
    {"building": "hq", "floor": "1", "zone": "cafe", "sensor": "hq-1-cafe", "capacity": 50, "offset": 0.7},
    {"building": "hq", "floor": "2", "zone": "lab", "sensor": "hq-2-lab", "capacity": 20, "offset": 0.5},
    {"building": "annex", "floor": "1", "zone": "design_studio", "sensor": "annex-1-design", "capacity": 24, "offset": -0.2},
    {"building": "annex", "floor": "2", "zone": "meeting_room", "sensor": "annex-2-meeting", "capacity": 10, "offset": 0.1},
]

def occupancy_for(zone: dict[str, object], ts: datetime, rng: random.Random) -> int:
    hour = ts.hour + ts.minute / 60
    weekday = ts.weekday() " 5
    capacity = int(zone["capacity"])
    name = str(zone["zone"])

    if not weekday:
        base = 0
    elif 8 "= hour " 18:
        profile = {
            "open_office": 0.64,
            "conference_a": 0.34,
            "cafe": 0.18,
            "lab": 0.48,
            "design_studio": 0.70,
            "meeting_room": 0.28,
        }[name]
        curve = 0.82 + 0.18 * math.sin((hour - 8) * math.pi / 10)
        base = round(capacity * profile * curve)
    else:
        base = 0

    if weekday and name == "cafe" and 11.5 "= hour " 13.5:
        base = round(capacity * 0.88)
    if ts.weekday() == 1 and name == "conference_a" and 14 "= hour " 16:
        base = capacity
    if ts.weekday() == 3 and name == "design_studio" and 9 "= hour " 12:
        base = round(capacity * 0.92)

    return max(0, min(capacity, base + rng.randint(-1, 1)))

def values_for(zone: dict[str, object], ts: datetime, rng: random.Random):
    occupancy = occupancy_for(zone, ts, rng)
    capacity = int(zone["capacity"])
    hour = ts.hour + ts.minute / 60
    zone_name = str(zone["zone"])
    diurnal = math.sin((hour - 7) * math.pi / 12)
    load = occupancy / capacity if capacity else 0

    temperature = 21.3 + float(zone["offset"]) + 1.3 * diurnal + 1.1 * load + rng.uniform(-0.18, 0.18)
    humidity = 43.0 - 4.0 * diurnal + 3.0 * load + rng.uniform(-0.8, 0.8)
    co2 = round(430 + 530 * load + rng.uniform(-18, 18))
    pm25 = 5.2 + 2.8 * load + rng.uniform(-0.7, 0.7)
    power = 0.65 + 0.10 * occupancy + max(0.0, temperature - 23.0) * 0.42 + rng.uniform(-0.12, 0.12)

    # Deterministic incidents used by the dashboard.
    if ts.weekday() == 1 and zone_name == "conference_a" and 14 "= hour " 16:
        co2 += round(720 + 80 * math.sin((hour - 14) * math.pi / 2))
    if ts.weekday() == 3 and zone_name == "design_studio" and 9 "= hour " 12:
        co2 += round(560 + 70 * math.sin((hour - 9) * math.pi / 3))
    if ts.weekday() == 4 and 9 "= hour " 14:
        pm25 += 20 + 4 * math.sin((hour - 9) * math.pi / 5)
    if ts.weekday() == 2 and zone_name == "lab" and 19 "= hour " 22:
        power += 5.5

    return (
        occupancy,
        round(temperature, 2),
        round(humidity, 2),
        int(co2),
        round(pm25, 2),
        round(max(power, 0.1), 2),
    )

def main() -> None:
    output = Path("smart-building.lp")
    rng = random.Random(20260821)
    rows = 0

    with output.open("w", encoding="utf-8") as handle:
        for tick in range(POINTS_PER_ZONE):
            ts = START + tick * INTERVAL
            epoch_s = int(ts.timestamp())

        for zone in ZONES:
                occupancy, temperature, humidity, co2, pm25, power = values_for(zone, ts, rng)
                tags = (
                    f"building={zone['building']},floor={zone['floor']},"
                    f"zone={zone['zone']},sensor_id={zone['sensor']}"
                )
                fields = (
                    f"temperature_c={temperature:.2f},humidity_pct={humidity:.2f},"
                    f"co2_ppm={co2}i,pm25_ug_m3={pm25:.2f},power_kw={power:.2f},"
                    f"occupancy={occupancy}i,capacity={zone['capacity']}i"
                )
                handle.write(f"building_telemetry,{tags} {fields} {epoch_s}\n")
                rows += 1

    print(f"wrote {rows} deterministic rows to {output}")

if __name__ == "__main__":
    main()

Run the generator:

python3 generate.py
wc -l smart-building.lp

Expected output:

wrote 12096 deterministic rows to smart-building.lp
12096 smart-building.lp

You can open smart-building.lp in your editor to inspect the line protocol. Each line contains:

Tags: building, floor, zone, and sensor_id are low-cardinality dimensions used for filtering and grouping.
Fields: temperature, humidity, CO₂, PM2.5, power, occupancy, and capacity are values that change over time.
Timestamp: epoch seconds—the ingestion command will specify --precision s.

Add an InfluxDB Python Processing Engine Plugin

Raw sensor values are valuable, but operators usually want a smaller set of decisions: Is the room healthy? How urgent is the problem? What should someone check?

Create plugins/iaq_assessment.py in your editor and paste this code:

"""Create dashboard-ready indoor-air-quality assessments from raw telemetry.

InfluxDB 3 injects LineBuilder and influxdb3_local at runtime.
"""

def _classify(row):
    co2 = int(row["co2_ppm"])
    pm25 = float(row["pm25_ug_m3"])
    temperature = float(row["temperature_c"])
    humidity = float(row["humidity_pct"])
    occupancy = int(row["occupancy"])
    power_kw = float(row["power_kw"])

    co2_component = min(70, max(0, round((co2 - 800) / 8)))
    pm_component = min(30, max(0, round((pm25 - 8) * 2)))
    comfort_component = (
        10
        if temperature " 20
        or temperature > 25
        or humidity " 30
        or humidity > 60
        else 0
    )
    risk_score = min(100, co2_component + pm_component + comfort_component)

    if risk_score >= 70:
        severity = "critical"
    elif risk_score >= 45:
        severity = "high"
    elif risk_score >= 20:
        severity = "moderate"
    else:
        severity = "normal"

    if co2 > 1000 and occupancy > 0:
        recommendation = "increase_ventilation"
    elif pm25 > 25:
        recommendation = "check_filtration"
    elif comfort_component:
        recommendation = "balance_hvac"
    else:
        recommendation = "monitor"

    energy_waste_kw = max(0.0, power_kw - 1.5) if occupancy == 0 else 0.0
    return risk_score, severity, recommendation, energy_waste_kw

def process_writes(influxdb3_local, table_batches, args=None):
    processed = 0

    for table_batch in table_batches:
        if table_batch["table_name"] != "building_telemetry":
            continue

        for row in table_batch["rows"]:
            risk_score, severity, recommendation, energy_waste_kw = _classify(row)
            line = (
                LineBuilder("iaq_assessment")
                .tag("building", row["building"])
                .tag("floor", row["floor"])
                .tag("zone", row["zone"])
                .tag("severity", severity)
                .int64_field("risk_score", risk_score)
                .int64_field(
                    "co2_excess_ppm", max(0, int(row["co2_ppm"]) - 800)
                )
                .string_field("recommendation", recommendation)
                .float64_field("energy_waste_kw", energy_waste_kw)
                .bool_field("occupied", int(row["occupancy"]) > 0)
                .time_ns(int(row["time"]))
            )
            influxdb3_local.write(line)
            processed += 1

    influxdb3_local.info(
        f"iaq_assessment processed {processed} building_telemetry rows"
    )

The plugin deliberately uses only the API InfluxDB injects and the Python standard library, so you don’t have to install any packages.

Understanding the Risk Calculation

CO₂ component     = clamp(round((co2_ppm - 800) / 8), 0, 70)
PM2.5 component   = clamp(round((pm25_ug_m3 - 8) × 2), 0, 30)
comfort component = 10 outside 20–25 °C or 30–60% humidity
risk score        = min(100, all three components added together)

The score becomes one of four states:

Score	Severity
0–19	normal
20–44	moderate
45–69	high
70–100	critical

The rules are intentionally simple and transparent. They are tutorial logic, not a health, safety, or regulatory standard.

The plugin also calculates energy_waste_kw. When occupancy is zero, it counts only power above a conservative 1.5 kW idle baseline. This is different from counting all energy used while a room is empty, which is shown in the dashboards.

Raw and derived table schemas

The first write creates the raw building_telemetry table:

The plugin creates iaq_assessment:

Columns	Stored as
building, floor, zone, sensor_id	Tags
temperature_c, humidity_pct, pm25_ug_m3, power_kw	Float fields
co2_ppm, occupancy, capacity	Integer fields
time	Timestamp

Keeping the raw and derived data separate makes the model easy to audit. You can inspect the original readings without reverse-engineering a transformed table, while Grafana can query the already classified states.

Test the Plugin Before Connecting it to Writes

InfluxDB can run a WAL plugin against a sample row without committing its output. This is the quickest way to catch syntax errors or confirm the scoring logic. The Processing Engine testing guide describes this behavior.

Run:

influxdb3 test wal_plugin \
  --database "$INFLUXDB_DATABASE" \
  --lp "building_telemetry,building=test,floor=1,zone=test,sensor_id=test temperature_c=22.0,humidity_pct=45.0,co2_ppm=1200i,pm25_ug_m3=10.0,power_kw=2.0,occupancy=4i,capacity=10i 1786406400000000000" \
  iaq_assessment.py

Expected: one derived iaq_assessment line, no errors, risk score 54, severity high, and recommendation increase_ventilation.

The risk is 54 because CO₂ contributes 50 points, PM2.5 contributes 4, and temperature and humidity add zero.

Mistake to avoid: The final argument is relative to the server’s --plugin-dir, not your terminal’s current directory. Because the server started with plugins as its plugin directory, the correct value is iaq_assessment.py.

Create the Trigger and Ingest Sample Data

Create a WAL trigger that watches only the raw table:

export INFLUXDB_TRIGGER="smart_building_iaq_assessment"
influxdb3 create trigger \
  --database "$INFLUXDB_DATABASE" \
  --path iaq_assessment.py \
  --trigger-spec "table:building_telemetry" \
  --error-behavior disable \
  "$INFLUXDB_TRIGGER"

The table scope is important. The plugin writes to iaq_assessment; because the trigger watches only building_telemetry, those derived writes cannot invoke the plugin recursively. The code also ignores batches from other tables as a second guard.

Write all 12,096 source rows:

influxdb3 write \
  --database "$INFLUXDB_DATABASE" \
  --precision s \
  --file smart-building.lp

InfluxDB acknowledges the source write separately from completing asynchronous Processing Engine work. Poll the derived count for up to 60 seconds:

derived_rows=0
for attempt in $(seq 1 60); do
  derived_rows=$(
    influxdb3 query \
      --database "$INFLUXDB_DATABASE" \
      --format csv \
      "SELECT COUNT(*) AS derived_rows FROM iaq_assessment" |
      tail -n 1
  )

  if [[ "$derived_rows" == "12096" ]]; then
    break
  fi

  sleep 1
done

printf 'Derived rows: %s\n' "$derived_rows"

Expected:

Derived rows: 12096

If the count does not reach 12,096, do not continue to Grafana yet. Review the troubleshooting section and inspect the InfluxDB terminal for Processing Engine errors.

Disable the trigger after enrichment finishes:

influxdb3 disable trigger \
  --database "$INFLUXDB_DATABASE" \
  "$INFLUXDB_TRIGGER"

In a real streaming application, you would normally leave a healthy trigger enabled so future writes are enriched.

Query the Results with SQL

Start by validating the raw table:

influxdb3 query \
  --database "$INFLUXDB_DATABASE" \
  "SELECT
     COUNT(*) AS source_rows,
     COUNT(DISTINCT building) AS buildings,
     COUNT(DISTINCT zone) AS zones,
     MIN(time) AS first_time,
     MAX(time) AS last_time
   FROM building_telemetry"

Expected values:

source_rows: 12096
buildings: 2
zones: 6
first_time: 2026-08-10T00:00:00
last_time: 2026-08-16T23:55:00

Now summarize the derived table:

influxdb3 query \
  --database "$INFLUXDB_DATABASE" \
  "SELECT
     COUNT(*) AS derived_rows,
     MIN(risk_score) AS min_risk,
     MAX(risk_score) AS max_risk,
     SUM(
       CASE
         WHEN severity IN ('high', 'critical') AND occupied THEN 1
         ELSE 0
       END
     ) AS unhealthy_occupied_intervals,
     ROUND(SUM(energy_waste_kw) * 5.0 / 60.0, 2) AS avoidable_kwh
   FROM iaq_assessment"

Expected values:

derived_rows: 12096
min_risk: 0
max_risk: 71
unhealthy_occupied_intervals: 62
avoidable_kwh: 9.29

Finally, find the CO₂ hotspots and empty-zone consumption:

influxdb3 query \
  --database "$INFLUXDB_DATABASE" \
  "SELECT
     building,
     zone,
     MAX(co2_ppm) AS peak_co2_ppm,
     ROUND(AVG(pm25_ug_m3), 2) AS avg_pm25_ug_m3

The first two rows should be hq/conference_a at 1,770 ppm and annex/design_studio at 1,572 ppm. The hq/lab row should have the largest raw empty-zone consumption at 61.22 kWh.

Installing Grafana

Install Grafana OSS from Grafana Labs’ signed APT repository:

sudo apt-get install -y apt-transport-https wget gnupg

sudo mkdir -p /etc/apt/keyrings
sudo wget -O /etc/apt/keyrings/grafana.asc \
  https://apt.grafana.com/gpg-full.key
sudo chmod 644 /etc/apt/keyrings/grafana.asc

echo "deb [signed-by=/etc/apt/keyrings/grafana.asc] https://apt.grafana.com stable main" |
  sudo tee /etc/apt/sources.list.d/grafana.list

sudo apt-get update
sudo apt-get install -y grafana

Start Grafana and enable it at boot:

sudo systemctl daemon-reload
sudo systemctl enable --now grafana-server.service
sudo systemctl status --no-pager grafana-server.service

Open http://localhost:3000 in your browser. On a new installation, the default username and password are both admin; Grafana immediately prompts you to choose a new password.

Use a unique local password supplied as $GRAFANA_ADMIN_PASSWORD. Never reuse the InfluxDB token as a Grafana password.

Create a Read-Only Token for Grafana

Grafana only needs to query this one database. It should not receive the administrator token used for setup.

In the terminal where INFLUXDB3_AUTH_TOKEN is still set, run:

influxdb3 create token \ –permission “db:smart_building:read” \ –name “Grafana read-only access to smart_building”

Store the returned value in your password manager as $INFLUXDB_GRAFANA_TOKEN. InfluxDB’s resource-token documentation explains the db:"database":read permission format.

Do not paste this token into a text file or include it in a screenshot. Enter it once in Grafana’s secure token field.

Connect Grafana to InfluxDB 3

In Grafana:

Open Connections → datasources.
Click Add new datasource.
Select InfluxDB. This is the built-in datasource; do not install another plugin.
Enter InfluxDB 3 Smart Building as the name.
Configure the connection:

Setting	Value
URL	http://127.0.0.1:8181
Query language	SQL
Database	smart_building
Token	The securely stored $INFLUXDB_GRAFANA_TOKEN value
Insecure Connection	Enabled

Click Save & test.

SQL uses Flight SQL over gRPC. Because both programs are on the same machine and the URL uses local HTTP without TLS, Insecure Connection is required. This setting disables gRPC TLS; it is not a recommendation for traffic crossing an untrusted network.

The URL is interpreted by the Grafana server, not by your browser. 127.0.0.1 works here because Grafana and InfluxDB run on the same machine. If you later move either service into a container or another machine, update the URL to an address reachable from the Grafana backend while keeping the connection private.

Create the Grafana Dashboard and Variables

Create the dashboard first:

Open Dashboards.
Click New → New Dashboard.
Save it as Smart Building Operations.
Set the dashboard timezone to UTC.
Set the absolute time range from 2026-08-10 00:00:00 through 2026-08-17 00:00:00.

The fixed range matters because this is historical data generated in a specific time range. A relative range such as “Last 7 days” will not include it.

Add the Building Variable

While editing the dashboard, click Add → Variable and configure:

Option	Value
Variable type	Query
Name	`building`
Label	Building
datasource	InfluxDB 3 Smart Building
Multi-value	Enabled
Include All	Enabled

Use this SQL query:

SELECT DISTINCT
  building AS __text,
  building AS __value
FROM building_telemetry
ORDER BY building

The preview should show annex and hq. Save the variable.

Add the Zone Variable

Add another query variable:

Option	Value
Name	`zone`
Label	Zone
datasource	InfluxDB 3 Smart Building
Multi-value	Enabled
Include All	Enabled

Use:

SELECT DISTINCT
  zone AS __text,
  zone AS __value
FROM building_telemetry
WHERE building IN (${building:sqlstring})
ORDER BY zone

This is a chained variable: changing Building refreshes the relevant Zone choices. For multi-value SQL variables, use IN and ${variable:sqlstring}. Grafana supplies correctly quoted SQL strings; do not add another pair of quotes around the variable. See InfluxDB template variables for more examples.

Set both variables to All before creating the panels.

Building the Grafana dashboard panels

For each panel, click Add → Visualization, select InfluxDB 3 Smart Building, switch the query editor to SQL code mode if necessary, paste the query, choose the indicated format and visualization, then apply the panel.

Every query uses two Grafana features:

$__timeFilter(time) expands to the dashboard’s active time range.
${building:sqlstring} and ${zone:sqlstring} expand the multi-select variables into quoted SQL values.

Grafana documents the available SQL macros in its InfluxDB query editor reference.

Peak CO₂ Dashboard

This stat answers, “What was the highest CO₂ reading in the selected scope?”

SELECT MAX(co2_ppm) AS "Peak CO₂ ppm"
FROM building_telemetry
WHERE $__timeFilter(time)
  AND building IN (${building:sqlstring})
  AND zone IN (${zone:sqlstring})

Configure:

Visualization: Stat
Format: Table
Unit: ppm
Title: Peak CO₂

With all buildings and zones selected, expect 1,770 ppm.

Keep the color neutral unless you have documented, context-appropriate CO₂ thresholds. A peak value alone does not describe duration, sensor accuracy, or local health policy.

Unhealthy Occupied Intervals Dashboard

This panel counts five-minute zone intervals that the plugin classified as high or critical while someone was present:

SELECT COUNT(*) AS "Unhealthy occupied intervals"
FROM iaq_assessment
WHERE $__timeFilter(time)
  AND building IN (${building:sqlstring})
  AND zone IN (${zone:sqlstring})
  AND severity IN ('high', 'critical')
  AND occupied = true

Configure:

Visualization: Stat
Format: Table
Unit: short
Title: Unhealthy occupied intervals

Expected result: 62. This means 62 five-minute zone records, not 62 separate incidents.

Energy While Empty Dashboard

The source cadence is five minutes, so kWh for one row is power_kw × 5/60. This query integrates every interval with zero occupancy:

SELECT ROUND(
  SUM(
    CASE
      WHEN occupancy = 0 THEN power_kw * 5.0 / 60.0
      ELSE 0
    END
  ),
  2
) AS "Empty-zone kWh"
FROM building_telemetry
WHERE $__timeFilter(time)
  AND building IN (${building:sqlstring})
  AND zone IN (${zone:sqlstring})

Configure:

Visualization: Stat
Format: Table
Unit: kWh
Title: Energy while empty

CO₂ by Zone Dashboard

A raw five-minute series is readable, but a 15-minute average makes the incident shape easier to compare across zones:

SELECT
  date_bin(
    INTERVAL '15 minutes',
    time,
    TIMESTAMP '1970-01-01T00:00:00Z'
  ) AS time,
  zone,
  AVG(co2_ppm) AS "CO₂ ppm"
FROM building_telemetry
WHERE $__timeFilter(time)
  AND building IN (${building:sqlstring})
  AND zone IN (${zone:sqlstring})
GROUP BY 1, 2
ORDER BY 1

Configure:

Visualization: Time series
Format: Time series
Unit: ppm
Legend: table, with maximum displayed
Title: CO₂ by zone

The result contains 672 series rows: 112 quarter-hour bins × six zones. A time series query must return a timestamp column; naming it time keeps the Grafana mapping straightforward.

Indoor Air Quality State Dashboard

SELECT time, zone, severity
FROM iaq_assessment
WHERE $__timeFilter(time)
  AND building IN (${building:sqlstring})
  AND zone IN (${zone:sqlstring})
ORDER BY time

Configure:

Visualization: State timeline
Format: Time series
Title: Indoor-air-quality state

Add value mappings:

Value	Label	Suggested color
`normal`	Normal	Green
`moderate`	Moderate	Yellow
`high`	High	Orange
`critical`	Critical	Red

Wasted Energy Dashboard

The plugin’s energy signal shows how much power exceeded the 1.5 kW baseline while the zone was empty.

SELECT
  date_bin(
    INTERVAL '15 minutes',
    time,
    TIMESTAMP '1970-01-01T00:00:00Z'
  ) AS time,
  zone,
  AVG(energy_waste_kw) AS "Excess kW wasted"
FROM iaq_assessment
WHERE $__timeFilter(time)
  AND building IN (${building:sqlstring})
  AND zone IN (${zone:sqlstring})
GROUP BY 1, 2
ORDER BY 1

Configure:

Visualization: Time series
Format: Time series
Draw style: bars
Stacking: normal
Unit: kW
Title: Energy wasted

The derived weekly total is 9.29 kWh, concentrated in the lab’s Wednesday evening event. Panel 3’s 316.04 kWh and this 9.29 kWh are intentionally different—the second number is more conservative.

Risk by Zone Dashboard

This query compares each zone’s normal operating level with its worst interval:

SELECT
  zone,
  ROUND(AVG(risk_score), 1) AS "Average risk",
  MAX(risk_score) AS "Peak risk"
FROM iaq_assessment
WHERE $__timeFilter(time)
  AND building IN (${building:sqlstring})
  AND zone IN (${zone:sqlstring})
GROUP BY zone
ORDER BY "Peak risk" DESC

Configure:

Visualization: Bar gauge
Format: Table
Minimum: 0
Maximum: 100
Unit: none—the score is bounded from 0 to 100 but is not a percentage
Title: Risk by zone

Operational Hotspots Dashboard

Finish with a table that puts ventilation and energy context together:

SELECT
  building,
  zone,
  MAX(co2_ppm) AS peak_co2_ppm,
  ROUND(AVG(pm25_ug_m3), 1) AS avg_pm25,
  ROUND(
    SUM(CASE WHEN occupancy = 0 THEN power_kw * 5.0 / 60.0 ELSE 0 END),
    2
  ) AS empty_zone_kwh
FROM building_telemetry
WHERE $__timeFilter(time)
  AND building IN (${building:sqlstring})
  AND zone IN (${zone:sqlstring})
GROUP BY building, zone
ORDER BY peak_co2_ppm DESC

Configure:

Visualization: Table
Format: Table
Sort: peak_co2_ppm, descending
Title: Operational hotspots

The table should contain six rows. conference_a ranks first for CO₂, while the lab leads in raw empty-zone energy, a useful reminder that air quality and energy efficiency reveal different operational problems. Save the dashboard after adding all eight panels.

Where to take the project next?

You now have a complete InfluxDB 3 and Grafana stack running locally. Telemetry is written as line protocol, with a Python plugin enriching every row as it lands, a derived table storing decisions rather than measurements, and a Grafana dashboard querying both. The pattern is worth more than just this project. The plugin is roughly fifty lines of standard-library Python. The trigger is table-scoped so it cannot recurse. The raw table is untouched, so if you decide next month that 800 ppm was the wrong CO₂ threshold, you can rewrite the scoring and recompute from source. And because the enrichment happens once at write time, every dashboard panel stays a short, readable query.

Grafana Features to Try

You built eight panels in this tutorial, but that’s only a fraction of what Grafana can do:

Transformations - Join building_telemetry and iaq_assessment on time and zone, then use Organize fields and Add field from calculation to build a combined table without writing a more complex SQL query.
Data links and drill-downs - Turn each row of the Operational hotspots table into a link that opens a zone-scoped view with the zone variable pre-set. It’s a two-minute change that makes the dashboard feel like an application.
Ad hoc filters - An ad hoc filter variable lets viewers add their own building = hq style constraints at view time without editing any query.
Canvas and Geomap - Canvas can overlay live severity colors on a floor plan image; Geomap does the same on a real map if your zones carry coordinates. Both are far more legible to non-technical stakeholders than a time series.
Explore mode - Prototype SQL against the datasource without creating a panel first—the fastest way to iterate on a query.
Dashboards as code - Export the dashboard JSON and check it into version control, or use Grafana provisioning to deploy the datasource and dashboard together on a fresh machine.

InfluxDB 3 Features to Try

The Processing Engine plugin you wrote is one trigger type among several, and InfluxDB has caching and lifecycle features that pair directly with what you just built:

Scheduled triggers - WAL triggers run inline on the write path, so they should stay cheap. A scheduled trigger runs on an interval or cron expression instead. These are great for hourly and daily rollups, anomaly detection over a window, or anything that needs to look across many rows rather than one.
Rollup tables - Have a scheduled trigger write a zone_hourly summary. Dashboards over long ranges then read a small pre-aggregated table instead of scanning weeks of five-minute data.
HTTP request triggers - Expose a plugin at an endpoint, and you have a small API—a current-status lookup for a room display, or a webhook that returns the top three zones to investigate.
Last Value Cache - Keeps the most recent value per series in memory for very fast lookups, which suits “current state” stat panels and real-time displays far better than a MAX(time) subquery.
Distinct Value Cache - Speeds up exactly the kind of query your Building and Zone template variables run, like SELECT DISTINCT over a tag column. On a large deployment, this is the difference between dashboards that load instantly and dashboards that stall on variable refresh.
Retention periods - Set a retention period on the database so raw five-minute data expires while your rollup table keeps the long history. This is the standard way to control storage cost in time series systems.
InfluxDB 3 Explorer - A browser UI for browsing databases and prototyping queries, handy when you want to check a table’s shape without dropping into the CLI.

Get started with InfluxDB 3 and Grafana

If you have not set up InfluxDB 3 yet, start a free InfluxDB 3 Enterprise trial or download InfluxDB 3 Core from the InfluxData downloads page, then follow the installation guide. The full Processing Engine reference is in the InfluxDB 3 documentation.

Built something with this pattern? A different plugin, a better scoring model, a dashboard for a domain we didn’t think of? Share it in the InfluxData Community forums. Questions are welcome there too.

Democratizing Breach Detection: How SMBs Can Build Their Own Time Series Security Monitor

Peter Albert, Jamie Strandboge (InfluxData) — Thu, 27 Aug 2026 08:00:00 +0000

When people hear that the average breach lifecycle still spans hundreds of days, they often blame inefficiency or apathy. The reality is that most teams, especially those in SMBs, are flying blind and relying on logs scattered across dozens of SaaS platforms. The information needed to understand a breach is there, but it often sits behind paywalls or is delivered without enough context to form a coherent picture.

When security events are modeled as time series, they form a continuous stream of behavior rather than isolated snapshots. File downloads, admin actions, and authentication attempts shift from static snapshots to dynamic patterns. Once everything is tracked as a sequence over time, the early signs of trouble become visible far earlier than the consequences do.

Digital Supply Chain Observability

That realization wasn’t theoretical for us. A few years ago, a third-party tool in our pipeline was compromised, and the SaaS didn’t detect it—one of the SaaS’s other customers did. By the time we found out, it was four months since the incident had occurred. That delay made it clear we needed to detect anomalies ourselves, without a full SIEM team or a seven-figure budget.

While that incident wasn’t the sole reason why we did what we did next, it was a catalyst to take security observability into our own hands. We started building an internal monitoring architecture we call DiSCO: Digital Supply Chain Observability. It’s a lightweight, time series-driven system that ingests audit logs from key SaaS platforms we rely on and turns them into an ordered stream of behavior.

The diagram below demonstrates the core idea: small collectors on the left, data collection via Telegraf in the middle, a time series database at the center, and dashboards and alerting tools on the right.

DIY time series security

You don’t need to rebuild DiSCO exactly, but you can build your own version. Here’s a practical path to developing a time series security detection tool without breaking the bank:

Step 1: Map Your Critical SaaS Surface

Start by nominating 5-10 SaaS services critical to your operations or risk profile, such as messaging apps, developer platforms, identity management providers, or financial systems.

Step 2: Secure Access to Audit Logs

Next, determine whether those SaaS tools provide audit logs and what it costs to access them. Many vendors tie log access to higher-priced enterprise plans. While that can feel like a dead end for SMBs, some providers offer off-market plans that include logs without dramatically increasing cost. Continue the conversation and don’t be afraid to negotiate.

If you truly cannot get logs from a particular service, document the gap and revisit it annually.

Step 3: Build Small, Safe Collectors

Once you’ve secured access, you need a way to pull the logs. DiSCO uses a set of small Python applications that:

Authenticate to each SaaS API using a narrowly scoped, read-only token.
Pull new audit events on a schedule.
Hand those events off to a local endpoint for further processing.

You can hand-code these collectors or have an AI system help. Just maintain strict token hygiene: minimal scope, read-only access, and frequent rotation to limit blast radius if a token leaks.

Step 4: Relay Everything Through a Data Collection Agent

Our collectors don’t write directly into the database, but instead send events to a self-hosted Telegraf instance that acts as a buffer and relay. You don’t have to use Telegraf, but its purpose-built support for time series, open source model, and batching capabilities make it a strong option. Events are written into a time series database using line protocol, providing resilience against transient failures.

For storage, you have options:

A purpose-built time series database optimized for high-ingest, high-cardinality data
A relational database (expect more overhead as volume grows)

The core requirement is simple: efficient handling of time-stamped events at scale.

Step 5: Design a Schema That Separates Events from Actions

When logs land, DiSCO writes them into three primary tables or buckets:

A raw logs bucket that stores unmodified SaaS data
A derived actions table with extracted actor, action, IP address, and country information per origin (SaaS)
A normalized events bucket that captures behaviors like logins, downloads, token creation, privilege changes, etc.

To preserve privacy and simplify correlation, we map user identities to UUIDs before storing them in derived tables. Names remain in raw logs for forensics but are excluded from routine monitoring.

Step 6: Add a Simple Inference Engine

With actions normalized and interleaved by time, you can start asking meaningful questions. DiSCO began with a simple inference engine—essentially SQL queries encoding what normal behavior looks like.

We learned typical login times, countries, IP ranges, and action frequencies, then alerted when behavior deviated from those baselines, such as access from a new or suspicious country.

These are basic signals, but they dramatically shorten detection timelines compared to waiting for vendor notification.

Step 7: Layer on Dashboards and a Time Machine

On top of this, we used Grafana to visualize organization-wide behavior at a glance. Because everything is stored as time series data, you gain a “time machine” that lets you replay historical events after improving parsers or adding new logic.

The point: democratize detection

Most SMBs don’t have the budget or staffing to deploy and operate a full SIEM, but they can access SaaS audit logs, write basic collectors, and use free, open source tooling. That’s enough to build a DiSCO-like architecture and reclaim control over breach detection timelines.

If you want to shorten your breach lifecycle, map your SaaS surface, get the logs, normalize events, and learn what “normal” looks like. Then start asking the only question that really matters in breach detection: What just changed?

You don’t need perfect coverage to get value, but you do need motion. The story of a breach is easier to read when it unfolds on a timeline you can see in real-time.

FAQs

What is Digital Supply Chain Observability (DiSCO)?

DiSCO is a lightweight security monitoring architecture that turns audit logs from multiple SaaS platforms into an ordered stream of activity. This allows businesses to monitor their digital supply chain to detect anomalous behaviors without relying on vendor notifications directly.

How can an SMB build a security breach detection system without a SIEM?

An SMB can start by identifying 5-10 critical SaaS services their business relies on, get access to their audit logs, and then start collecting these logs using read-only APIs. The events can then be stored in a time series database for analysis and alerting.

Why is time series data useful for cybersecurity monitoring?

Time series allows you to know the order and timing of security events, making it easier to see patterns that logs alone might hide. Teams can use this data to establish baselines for things like login times, locations, IP addresses, and user activity. Any deviations from these baselines can be used to create alerts to trigger investigations.

How should SaaS audit logs be organized for security analysis?

A good starting point is to separate raw logs from normalized security events. Raw data is kept available for investigation, while the normalized data makes it easier to correlate behaviors like downloads or authentication attempts.

Telegraf Controller 1.1: Make Fleet-Wide Config Changes with a Single Edit

Scott Anderson (InfluxData) — Tue, 25 Aug 2026 00:25:00 +0000

Telegraf is easy to stand up. You just need a config file with a few plugins and data flows. That ease is why Telegraf fleets grow fast, and why managing the agents that collect data becomes more difficult than collecting it. A change that takes minutes on ten agents takes days across a few hundred. Telegraf Controller is a centralized control plane for managing, configuring, and monitoring your fleet of Telegraf agents.

Telegraf Controller 1.1 is available today and addresses that management problem from two sides: keeping the Controller layer itself reliable, and making fleet-wide changes without touching every config. The release adds high availability, configuration versioning, global constants, configuration groups, and aliases.

High availability (Telegraf Enterprise)

High availability lets you run multiple Controller instances from a shared database with automatic failover. If an instance goes down, agents keep pulling configuration and reporting health through the remaining instances.

For production monitoring, compliance systems, and other mission-critical pipelines, the configuration layer needs to meet the same reliability requirements as the rest of the stack. High availability also simplifies planned maintenance: one instance can go offline for patching and the config path stays open. In strict environments that require redundancy, it also removes Controller as a single point of failure.

Configuration versioning

Configuration versioning saves every configuration change as a new version, including who made it. If an edit causes errors, compare the current version against the previous one in a side-by-side, color-coded diff and revert.

Configuration history also provides an audit trail. Teams can trace when individual settings changed and test tuning changes without losing the last working configuration.

Global constants

Global constants let you define a value once (an output endpoint, a collection interval, a region name) and reference it from any configuration; updating the constant updates every configuration that references it.

Reference a constant anywhere in a configuration with the ::{constant_name} syntax. When Controller serves a configuration to an agent, it resolves each reference to the constant’s current value:

[agent]
  interval = "::{collection_interval}"

[[outputs.influxdb_v3]]
  urls = ["::{influxdb_url}"]
  token = "${INFLUX_TOKEN}"
  database = "::{metrics_database}"

The immediate benefit is consistency: shared values live in one place instead of being duplicated across dozens of configurations and drifting out of sync. Constants also simplify migrations: moving your fleet to a new output endpoint or standardizing collection intervals across teams becomes one edit instead of a config-by-config sweep.

Configuration groups

Configuration groups bundle multiple configurations into an ordered unit that agents retrieve in a single request. Instead of assigning each agent its own stack of individual configs, you assign the group.

Groups compose by reference, not by copy. A config can belong to multiple groups, and editing a config propagates the change to every group that includes it.

That’s what makes groups work as role profiles. Build one base config with the system inputs every host runs, then compose it with the configs specific to a web server or a database host. Tune the base config once and every role updates without maintaining separate copies that can drift. Groups also serve as templates. A group proven in production becomes the starting point for the next site or deployment, instead of another copy-paste job.

Configuration aliases

Configuration aliases let you use custom, human-readable identifiers for configs in both the UI and the API. Agents request web-baseline instead of a UUID, so when it’s time to move agents to a different config, simply move the alias and the fleet cuts over on the next pull.

If you are running multiple Controllers use a single alias to reference the same config on each instance rather than config UUIDs, which are unique to each Controller.

One change, fleet-wide

Constants, groups, and aliases are each useful on their own, but they’re designed to work together. If every site’s agents request the same group by alias, and that group’s configurations pull shared values from global constants, a fleet-wide change—a new endpoint or interval—is a single edit. Every site picks it up on its next config pull.

What’s free and what requires Telegraf Enterprise

Feature	Free	Enterprise
High availability	No	Yes
Configuration versioning	Yes	Yes
Configuration aliases	Yes	Yes
Global constants	Yes	Yes
Configuration groups	Yes	Yes

Get started

The value of Telegraf Controller 1.1 is a config path that stays up and is far less work to keep the fleet current. High availability maintains uptime through instance failures, so the layer serving your configs meets the same reliability as the rest of your stack. Shared values are defined once instead of copied across every config, and config changes reach the whole fleet on the next pull with a record of what moved and an easy revert if something went wrong.

Telegraf Controller 1.1 is available today. Download and install Telegraf Controller for free or contact us about Telegraf Enterprise.

FAQ

What's new in Telegraf Controller 1.1?

Telegraf Controller 1.1 adds high availability (Enterprise only), configuration versioning, global constants, configuration groups, and configuration aliases. Together, these allow a single edit, like a new output endpoint or collection interval, propagate across an entire fleet on the next agent config pull.

How does high availability work in Telegraf Controller?

High availability lets you run multiple Telegraf Controller instances against a shared database with automatic failover. If one instance goes down, agents keep pulling their configuration and reporting health through the remaining instances.

How do global constants work in Telegraf Controller?

Global constants let you define a value once (i.e. an output endpoint, collection interval, or region name) and reference it from any configuration using ::{constant_name} syntax. When Controller serves a config to an agent, it resolves the reference to the constant's current value, so updating the constant updates every configuration that uses it.

A Guide to Downsampling Time Series Data with InfluxDB 3

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

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

Why downsample time series data?

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

Downsampling helps you:

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

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

Choose Query-Time or Persisted Downsampling

InfluxDB 3 gives you two practical patterns for downsampling:

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

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

Prerequisites

To follow this tutorial, you need:

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

The examples assume a database named bird_demo:

influxdb3 create database bird_demo

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

Generate Sample Telemetry with the Official Bird Simulator

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

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

First, install the plugin’s Faker dependency:

influxdb3 install package Faker

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

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

SELECT *
FROM bird_tracking
ORDER BY time DESC
LIMIT 5;

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

Downsample at Query Time with SQL

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

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

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

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

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

Persist Downsampled Data with the Python Processing Engine

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

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

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

The trigger arguments control the rollup:

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

Why the Offset Matters

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

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

Inspect the Persisted Result

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

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

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

Sample Output

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

Validate the Reduction with SQL

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

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

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

Example Output

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

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

Downsampling best practices for production

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

When designing that pipeline:

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

Troubleshoot a scheduled downsampler

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

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

Then check the most common causes:

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

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

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

FAQs

What is downsampling?

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

How do I downsample data with InfluxDB 3 SQL?

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

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

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

How do I prevent partial downsampling windows?

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

Does downsampling delete the original data?

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

What does record_count mean in the downsampled table?

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

Can I calculate more than one aggregate per interval?

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

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

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

How much storage will downsampling save?

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

A Rust Client for InfluxDB 3

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

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

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

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

Why Rust, when Go and Python clients already exist?

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

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

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

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

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

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

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

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

Installation

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

cargo add influxdb3-client

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

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

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

Let Claude Write the Boilerplate

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

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

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

Configuring a client

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

use influxdb3_client::{Client, ClientConfig};

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

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

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

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

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

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

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

Writing data

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

Points

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

use influxdb3_client::{Point, Precision};

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

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

Raw Line Protocol

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

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

Write Options

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

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

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

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

Which Write Endpoint?

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

High-Throughput Ingest

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

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

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

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

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

            .await
    });
}

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

Querying data

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

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

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

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

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

Parameterized Queries

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

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

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

Working with Rows

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

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

Streaming Large Results

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

use futures_util::TryStreamExt;

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

Reliability

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

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

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

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

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

use influxdb3_client::Error;

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

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

Polars integration

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

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

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

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

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

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

Backfilling from Parquet Files

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

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

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

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

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

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

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

Loading CSV Exports

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

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

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

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

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

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

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

FAQ

What is `influxdb3-client?`

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

What Rust version does it require?

The crate requires Rust version 1.89 or later.

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

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

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

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

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

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

Is the Polars integration required?

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

Does it retry failed writes automatically?

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

Where do I report issues or request features?

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

Try it

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

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

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

Where Historians Fall Short for Physical AI

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

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

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

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

Where historians fall short for Physical AI

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

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

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

Retaining Operational History Versus a Live Model Feed

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

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

Compression Removes Relevant Signals for Model Training

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

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

The Cost of Fragmented Data

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

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

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

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

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

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

A modern time series architecture connects edge and cloud

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

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

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

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

Building a Context-Rich Training Dataset for Physical AI

Delivering Live Telemetry to AI at Inference

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

Built for the physical world

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

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

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

FAQ

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

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

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

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

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

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

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

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

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

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

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

InfluxDB 3.11 was built for that reality.

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

Performance and flexibility for heavier, more complex workloads

Faster Reads for Single-Series Workloads

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

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

More Room for Wide, Sparse, and Changing Schemas

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

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

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

More Predictable Performance Under Load

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

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

New data management capabilities for Enterprise

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

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

InfluxDB 3 Explorer UI, now built in

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

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

Get started with InfluxDB 3.11

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

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

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

AI-Powered Spacecraft Operations with InfluxDB 3

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

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

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

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

Demo overview

From Telemetry Stream to Operator Signal

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

Detecting Anomalies as Data Arrives

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

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

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

Accessing Operational Truth Using AI

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

Under the hood: From raw telemetry to operational context

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

Alerting on Real-Time Data

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

Onboard computer temperature
Reaction wheel RPMs
Power draw
Attitude status

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

Enriching Telemetry with Third Party Data

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

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

Integrated AI Agent Using the InfluxDB 3 MCP Server

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

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

Putting the processing engine to work

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

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

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

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

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

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

Check out the demo and start building

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

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

Resources

FAQs

How does the demo detect anomalies in real-time?

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

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

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

How can InfluxDB be used with an AI agent?

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

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

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

What is InfluxDB 3?

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

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

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

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

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

Processing Engine primer

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

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

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

SageMaker inference

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

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

Example: Anomaly Scoring with Built-In AWS Model

influxdb3 install package boto3
influxdb3 install package pandas

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

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

Value counter

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

Chronos forecasting

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

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

Example: On-Demand Forecast via HTTP

influxdb3 install package chronos-forecasting
influxdb3 install package torch

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

influxdb3 enable trigger --database mydb chronos_forecast_http

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

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

Simple data replicator

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

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

Example: Replicate Data on Every Write

influxdb3 install package influxdb3-python

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

influxdb3 enable trigger --database mydb simple_data_replicator_trigger

Stock portfolio tracker

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

Mix and match your plugins

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

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

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

FAQs

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

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

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

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

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

Q: Where do I see plugin errors or logs?

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

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

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

Inside LeoLabs: How Radar Engineers Track Over 27,000 Objects in Orbit with InfluxDB

Cole Bowden (InfluxData) — Tue, 21 Jul 2026 08:00:00 +0000

Every month, satellite operators perform thousands of orbital maneuvers as recommended by LeoLabs’ data. They don’t do it to reposition satellites, they do it to avoid hitting things.

With tens of thousands of active satellites and other debris circling the Earth, adding new devices to orbit comes with risk. Satellites are expensive, high-tech devices that require a massive investment to engineer and launch. This means that to get a return on that investment, companies need their satellites to last a long time and to avoid the hazards posed by other satellites and debris in similar orbits. Space is big, but it’s becoming increasingly crowded as investment in the commercial space sector skyrockets.

A satellite in low Earth orbit is unlikely to bump into something else on any given day, but when the expectation is that its lifespan will be on the scale of 5 to 10+ years—thousands of days—that small chance of collision becomes a greater risk. Collisions can take a satellite out, and without the necessary intelligence to avoid other objects around it, there’s no guarantee a satellite can last its full lifespan.

We sat down with Jackson Ball, a radar software engineer at LeoLabs, to talk about what his company is doing to monitor satellites and discuss how it’s using InfluxDB to track and leverage radar data. Armed with a massive stream of real-time data, LeoLabs enables satellite operations by handling the around-the-clock task of managing, monitoring, and positioning objects in orbit, ensuring that its customers don’t have to worry about the 10+ fragmentations a year that happen in space.

What is LeoLabs?

LeoLabs is a Silicon Valley-based space technology company that operates a global network of ground-based radars across the United States, Europe, Australia, and other regions. Its systems are designed to detect, track, and characterize satellites and debris in low Earth orbit, contributing to space traffic management, space domain awareness, and collision avoidance.

Rather than relying on existing communications infrastructure, LeoLabs uses purpose-built phased-array radar systems distributed around the world. Each radar actively transmits radio signals into space and measures the reflected returns from objects in orbit, capturing precise data on range, velocity, and position. By combining observations from multiple radar sites over time, LeoLabs builds and maintains a continuously updated catalog of tens of thousands of objects.

This networked approach allows them to revisit objects frequently and refine orbital estimates, enabling customers, which range from commercial satellite operators to defense organizations, to better understand and respond to activity in space.

The data infrastructure challenge

The comparatively easy part, at least from the perspective of data infrastructure, is tracking satellites and debris. LeoLabs can measure the position, velocity, etc., of an in-orbit object multiple times per day. This amounts to several million measurements per day across assets and several billion measurements to date. Because LeoLabs can more accurately project trajectories based on the quality of this data, the tracking results in hundreds of millions of conjunction data messages (CDMs) per month for their customers. A CDM is a report that’s generated when two objects in orbit are likely to have a close (if not head-on) approach. LeoLabs’ ability to deliver CDMs helps satellite operators perform thousands of maneuvers per month to avoid collisions.

If satellite and debris tracking is the “easy” part, the hard part is making sure that data can be trusted and is as high-fidelity as possible. LeoLabs’ collision avoidance product isn’t defined by the sheer volume of data it provides, but by the precision, reliability, and actionable insight that data drives. While the dataset of objects in orbit may only span gigabytes, it serves as a critical backbone for forecasting trajectories and determining when maneuvers will be required, ultimately enabling timely CDMs. On top of that, ongoing data collection powers an AI imaging system that helps analyze radio interferometry signals to identify and characterize debris clouds, further enhancing space situational awareness.

When forecasting orbits, tumbling, debris clouds, and covariance projections, data quality is paramount. But how do you ensure quality when the quantity of devices deployed around the globe is so high?

Each device that generates transmissions and readings needs to be monitored, connected to the network, and calibrated correctly to ensure all measurements are as accurate as possible. While an object in orbit may generate data multiple times a day, hardware on Earth communicates much more frequently. Information on radar transmission power, server metrics, physical hardware status, amplifiers, and environmental conditions is generated at massive volumes for monitoring and to be alerted on. At LeoLabs, this means 7,000 lines of data written every second, or 600 million lines per day. Needless to say, scale becomes a concern, and general-purpose data infrastructure simply can’t keep up.

LeoLabs + InfluxDB

LeoLabs operates a global radar network with a lean engineering team. Because its radar systems are distributed across multiple geographies, continuous, automated visibility into hardware health is essential to maintaining reliable operations. That visibility allows engineers to monitor performance, detect issues quickly, and keep the network operating with confidence.

The scale of monitoring required is what drove LeoLabs to InfluxDB. Each radar site generates health telemetry every second to every minute. They pass transmission power, server metrics, amplifier status, and environmental conditions across thousands of devices. After evaluating alternatives and experimenting with the open source version of InfluxDB, the team landed on InfluxDB Cloud Dedicated as the infrastructure that could handle the job.

Only a purpose-built time series database could handle the immense volume of data being generated by the many thousands of devices they own and operate, and by using InfluxData’s data collection agent, Telegraf, LeoLabs was able to easily move that data into a central InfluxDB instance. Its current stack is:

InfluxDB Cloud Dedicated: Central storage engine for all high-fidelity telemetry
Telegraf: Universal data agent used to collect and ingest data from radar infrastructure across the globe
NetBox + Ansible: NetBox serves as the source of truth for device configuration, while Ansible automatically generates and deploys updated Telegraf configurations via GitHub Actions

To power their data processing and analytics pipelines, LeoLabs retains several years of full-resolution telemetry history. Engineering teams use that historical data to investigate the long-term health and performance of its radar systems, and analyze how radar behavior changes alongside seasonal atmospheric conditions. Recent efforts have centered on processing this data to strengthen predictive maintenance models and apply machine learning techniques to uncover recurring patterns.

The result is that internally, LeoLabs can function with a proactive, data-driven operational model. Engineers have continuous automated visibility into the health and performance of radar systems across the global network.

InfluxDB plays a critical role in LeoLabs’ infrastructure, enabling a lean team to operate with confidence that potential issues will be detected and surfaced in real-time. By offloading the complexity of managing time series data at scale, engineers are free to focus on higher-impact work (such as optimizing their radar network) rather than maintaining and troubleshooting database systems.

With approximately 1,000 alert rules, it’s also pivotal that InfluxDB performs as well as it does. Processing millions of lines of data and checking each one for an alarm requires the efficiency that a purpose-built time series database can bring to the table, and the result is that “fast firing” alerts can trigger within 30 seconds anytime something goes amiss.

The number of tracked objects is growing by the day, and the frequency of close approaches is increasing. This makes the margin for error slim for satellite operators, launch providers, and defense agencies relying on accurate orbital intelligence. LeoLabs is operating at the intersection of growing complexity and real-time data infrastructure, with a lean team and a database layer that gives them confidence the system will surface a problem before it becomes one.

That’s what purpose-built time series infrastructure looks like in the real world: fast ingestion with operational confidence at scale across distributed, global hardware.

Telegraf 1.39 Release Notes

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

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

Telegraf 1.39 — Release notes

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

New plugins

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

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

Important changes

Here are some changes to highlight:

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

Downloads

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

InfluxDB University

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

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

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

Here’s everything that shipped.

Telegraf Enterprise reaches general availability

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

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

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

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

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

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

InfluxDB 3.9 and 3.10 close the gap before production

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

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

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

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

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

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

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

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

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

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

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

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

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

A few things people have asked us

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

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

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

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

Looking ahead

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

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

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

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

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

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

Convert Flux queries to SQL

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

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

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

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

Click Convert, and you get back SQL:

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

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

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

InfluxQL comes to the Data Explorer

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

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

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

InfluxQL visualizations, with per-tag series

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

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

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

Two new live sample data simulators

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

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

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

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

Quality-of-life improvements

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

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

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

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

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

Try Explorer 1.9

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

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

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

How Mumu Migrated From Prometheus to InfluxDB and Tripled Their Metric Coverage

Charles Mahler (InfluxData) — Thu, 25 Jun 2026 08:00:00 +0000

When a team uses an internal Slack channel for everything from contact form submissions to deployment alerts and server warnings, the notification engine quickly becomes critical infrastructure. When the same team builds that engine as a product for other teams to use, the bar gets even higher.

Mumu is an all-in-one productivity platform for modern teams. While most companies stitch together separate SaaS tools for org charts, agile estimation, internal Q&A, skill mapping, recognition, and notifications, Mumu offers all of those as connected modules under a single subscription. The premise is that your organizational structure shouldn’t be replicated across five different databases; it should live in one place and flow into every workflow your team uses.

In this blog, we will go over why the Mumu team rebuilt their monitoring stack on InfluxDB 3 and how the migration went.

Why pull-based monitoring stopped making sense

Like many teams running their own infrastructure, Mumu started off using Prometheus as its primary monitoring solution. The main problem over time was the fundamental mismatch between Prometheus’s pull-based data collection model and the type of data Mumu was working with. Rather than telemetry data that can be scraped at a regular interval, Mumu often needs to track discrete events like user triggered actions, scripts completing, and a pipeline finishing. As a result, push-based delivery for tracking events made more sense.

That architectural mismatch wasn’t the only problem. As Mumu evaluated alternatives like Betterstack, VictoriaMetrics, PostHog, Graphite, Datadog, and New Relic, issues related to transparency became a concern. Several of the SaaS solutions came with documentation that made it genuinely hard to understand what was happening under the hood, particularly around how metrics were ingested and stored. For a team that ships fast and needs to be able to debug its own pipeline, that was a dealbreaker.

Why InfluxDB 3 was the right option

Two things about InfluxDB stood out during evaluation. The first was that self-hosting was effortless. Mumu runs its own dedicated servers, and spinning up an InfluxDB 3 Core instance using the official Docker image took almost no time or configuration overhead.

The second factor was the push-based HTTP API. InfluxDB’s Line Protocol HTTP API lets Mumu’s services emit metrics at the exact line of code where an event occurred with no sidecar, no exposition format, no scrape interval, just a POST request at the moment an event happened.

In hindsight, the team’s biggest evaluation lesson was that they should have built a small proof of concept with InfluxDB earlier. The time spent evaluating other tools wasn’t wasted as it gave them context and confidence in the final decision, but InfluxDB’s simplicity would have been apparent within an afternoon.

Migration process

The migration involved three phases over a 3-month period: dual writing to InfluxDB and the existing Prometheus setup, validation, and finally, decommissioning the Prometheus infrastructure.

Phase 1: Dual-Writing via Vector

The first move was to make the same metrics flow into both systems at once. Mumu added InfluxDB as a second sink alongside Prometheus in their existing Vector pipeline, so every metric was being written to both simultaneously. That parallel run is what made the eventual cutover risk-free by allowing the team to confirm performance and validate both systems against each other.

Migrating to InfluxDB is made easy using AI agents.

About 80% of the migration work, such as Vector configuration changes, the dual-write sink setup, and the boilerplate around the new HTTP drivers in Go and TypeScript, was generated by coding agents.

A migration becomes a lot less daunting when the routine work compresses into hours, but what really made this work was what the agent had to work with on the InfluxDB side. InfluxDB 3 exposes a full REST API with a published OpenAPI specification. When an AI agent can read that contract directly, it doesn’t have to guess at parameter names from stale blog posts or hallucinate endpoint shapes from vague documentation. It reads the spec, generates correct client code, and gets the integration right on the first pass. InfluxDB also has an MCP server for integrating with AI agents, although it wasn’t used by Mumu.

This is an important property in a world where agents are doing more and more of the integration work. The systems that will be easiest to adopt over the next few years are not necessarily the ones with the most features, they’re the ones whose APIs are legible to machines.

Phase 2: Validation

Running two systems in parallel only helps if you actually compare them, and this is where the team spent its caution wisely. The validation approach was deliberately simple: they duplicated their Grafana panels side by side, with one panel pulling from Prometheus and an identical panel pulling from InfluxDB. When two panels showing the same metric look identical for weeks on end, confidence accumulates quickly.

Beyond visual parity, four things got specific attention:

Retention policies: Confirming data was being stored at the right granularity and for the expected duration.
Tag cardinality: Making sure the tagging strategy wouldn’t cause write-performance problems at scale. Keeping cardinality low on high-volume metric streams is a lesson the team internalized early.
Batch write behavior: Validating that the NestJS batching logic produced correct time series data with no gaps or duplicates.
Dashboard parity: Rebuilding key Grafana dashboards from scratch against InfluxDB to confirm they told the same story as their Prometheus equivalents.

Phase 3: Cutover

Because Mumu’s Go and TypeScript codebases already had proper abstractions and interfaces for metric delivery, writing a new driver that sent metrics to InfluxDB via the HTTP API required almost no changes to the application code. The abstraction layer in their app code meant that swapping the metrics backend was a contained, well-scoped task rather than a sprawling refactor.

The TypeScript driver came in at around 160 lines of code, largely because the team leaned on the official InfluxDB 3 client library package. The Go implementation was slightly longer due to manual HTTP handling, retry logic, and error handling, but was still a straightforward, bounded piece of work. Once the drivers were in place, the team decommissioned Prometheus for business metrics and declared the migration complete.

Benefits of InfluxDB 3—from 150 to 560 metrics

Before InfluxDB, Mumu collected around 150 metrics. Today, they collect 560 metrics, and that number is constantly increasing.

That growth didn’t come from a dedicated instrumentation initiative. There was no mandate, no quarter-long observability push, it happened organically because adding a new metric became a one-line HTTP call. When friction drops that far, engineers instrument things they would previously have skipped.

The number is less a measure of throughput than a measure of how much the team’s relationship with its own data changed once the cost of asking a question fell to nearly zero. And because metric delivery was suddenly cheap, Mumu started instrumenting things that would have seemed impractical before:

Operational automation: Mumu sends a metric for every command executed on their servers, with automations built on top using MsgGO, and certain commands automatically trigger a Slack alert. The result is passive visibility into operational activity with no manual reporting required.
CI/CD observability: They emit metrics from their Bitbucket pipelines, including how long each pipeline runs. Over time, this has established a baseline for normal build duration, making regressions easy to spot.
Per-developer environments: Every developer tags their metrics with an env field set to their local environment name, such as local:john, local:kate, and so on. Each developer can observe their own environment in Grafana, test new instrumentation locally before it ships, and build personal dashboards, all without polluting shared production data.
General script instrumentation: Bash scripts, custom CLI commands, and database migration durations during deployments are all now tracked, where before each would have demanded disproportionate effort.

SQL on time series data

Volume was not the only shift. InfluxDB 3’s SQL support meaningfully improved Mumu’s ability to build dashboards and debug metric data. Before the migration, querying time series data meant learning a specialized query language and reasoning about its particular semantics. With SQL, any engineer on the team can write an ad-hoc query to investigate a metric anomaly, validate that a new event is being tracked correctly, or prototype a Grafana panel without consulting documentation.

The qualitative win is harder to put a number on, but is equally important: the metrics are now trusted. Engineering time that used to go into questioning whether a dashboard was telling the truth now goes into acting on what it shows.

Architecture overview

Mumu runs entirely on its own dedicated servers, giving the team full control, room for hardware-level optimization, and predictable costs. The application layer runs on Docker, with services written in Go and NestJS; Go handles core infrastructure-level work while NestJS handles application layer operations.

Metrics reach InfluxDB along two paths. Vector collects and transforms log-based metrics from the server environment and forwards them to InfluxDB. The Go and NestJS services send business and application metrics directly over the HTTP API.

The tagging strategy reflects that split. Server-level and infrastructure metrics carry richer tag sets like env, container, process_name, process_instance, and service. Business and application metrics are tagged more lightly, typically just env plus a small number of domain-specific identifiers. On the NestJS side, metrics are batched and flushed either every 60 seconds or when the batch size crosses a configured threshold, which is a configuration the team continues to tune to balance data freshness against RAM usage and write overhead. Grafana sits on top of it all, querying InfluxDB directly.

Future plans for utilizing InfluxDB 3

For Mumu, InfluxDB has unlocked more than just an internal observability story. The team is now actively building toward making it a first-class part of their product surface.

The most immediate project is integrating InfluxDB as a delivery target inside MsgGO. Today, MsgGO routes messages to Slack, Telegram, Discord, Email, SMS, and Webhooks. Adding InfluxDB as a target means any system already sending events through MsgGO like contact forms, deployment notifications, server alerts, and application events, can now route structured event data directly into InfluxDB with no additional integration work. Since Mumu uses MsgGO heavily inside its own infrastructure, this would pay off immediately in its own workflows, with the customer-facing benefits coming close behind.

Further out, the team is evaluating whether to move user-activity statistics that are currently kept as activity records in a NoSQL database into InfluxDB. That data is inherently time series in nature, and putting it in InfluxDB would let them expose richer usage analytics inside the Mumu dashboard without needing a separate query infrastructure. And they want to lean on InfluxDB’s SQL interface to drive product decisions, using internal usage metrics to understand which modules see the most engagement, where users drop off, and how feature adoption shifts after a release.

Telegraf Enterprise Now Generally Available: Manage Telegraf Fleets at Scale

Scott Anderson (InfluxData) — Wed, 24 Jun 2026 06:00:00 +0000

Telegraf has become the standard for collecting telemetry across cloud, edge, and physical infrastructure. With more than five billion downloads and 400+ official plugins, Telegraf is the open source standard to connect virtually any data source to any destination.

Over the years, we’ve seen Telegraf evolve from a lightweight collection agent into a foundational part of production infrastructure. But as deployments grow, the challenge shifts from collecting telemetry to managing the systems that collect it. Large Telegraf deployments require consistent configurations across environments, clear visibility into fleet health, and safe rollout of changes to thousands of agents. Many teams rely on scripts, internal tools, and manual processes to manage this, but these approaches quickly break down as deployments scale.

Telegraf Enterprise is now generally available to address these challenges, giving teams a centralized way to manage configurations, monitor fleet health, and operate Telegraf deployments with tens of thousands of agents from a single system.

Centralized control for large Telegraf deployments

As Telegraf becomes more deeply embedded in production environments, visibility and consistency become increasingly important. Teams need to understand which agents are healthy, what configurations are running across environments, and whether changes have been deployed successfully. They also need a way to manage differences between regions, customers, and environments without creating hundreds of nearly identical configurations.

Telegraf Enterprise combines Telegraf Controller, a centralized management console for Telegraf, with official InfluxData support. Telegraf Controller provides a centralized way to manage those deployments. Teams can create and manage configurations centrally, assign them to agents, and monitor fleet health from a single interface. Configuration templates and parameter substitution make it possible to standardize shared configurations while still allowing environment-specific values where needed.

For organizations operating large Telegraf deployments, consistency is just as important as collection. Keeping configurations aligned across thousands of agents, while continuing to work with existing automation systems, can quickly become an operational challenge.

The visual configuration builder makes it easier to create and review configurations across Telegraf’s 400+ plugin ecosystem without manually authoring every line of TOML.

“We run thousands of Telegraf agents across diverse customer environments. Telegraf Controller will help us use our existing automation tools to keep agent configurations consistent and up to date across our fleet as we continue expanding our observability platform.” – Poul H. Sørensen, Senior Systems Consultant at Orange Business

Open source Telegraf remains unchanged. The agent, the plugin ecosystem, and community continue as they always have. Telegraf Controller’s free tier supports up to 20 configs and 100 agents, making it easy to get started with centralized fleet management.

What an Enterprise license buys you

As your fleet grows and more people touch your Telegraf configurations, the free tier’s limits start becoming constraints. Telegraf Enterprise removes those constraints and scales to your needs, offering:

Raised scale limits: The free version of Telegraf Controller makes it easy to get started and evaluate the product. A Telegraf Enterprise license raises the agent and configuration limits based on your licensed entitlement, allowing Telegraf Controller to grow with the size of your fleet.
Audit logging: Telegraf Enterprise records security-relevant and administrative events, including configuration changes, permission updates, agent actions, login activity, and license changes. This provides clearer operational history for troubleshooting, compliance, and security investigations.
Identity provider integration: Organizations can integrate Telegraf Enterprise with LDAP and OIDC rather than maintaining a separate user directory. For organizations using SSO or MFA through an identity provider, Telegraf Controller can integrate into that existing model.

Official support for Telegraf

Telegraf Enterprise adds an official InfluxData support path for organizations running Telegraf as part of their critical production infrastructure. Customers get support for both Telegraf Controller and the Telegraf agent, including installation, configuration, operational guidance, and troubleshooting assistance.

Upgrade in place

If you’re already running Telegraf Controller, there’s no separate Enterprise deployment or migration process. Add a valid license to your existing installation and the Enterprise capabilities unlock in place. The same deployment, agents, and configurations remain in place while additional scale, security, and support capabilities become available.

Get started

Telegraf Controller is available today with a free tier. Telegraf solved the problem of collecting telemetry from almost anywhere; Telegraf Enterprise helps teams operate that collection layer as it grows into critical infrastructure.

Download and install Telegraf Controller or contact us about Telegraf Enterprise.

FAQ

What happens to configurations and agents that exceed the free tier limits—are they deleted, or just blocked?

Existing resources aren't deleted when you hit the limit. Telegraf Controller enforces limits on creating new configurations and agents; once you're at capacity, "create" endpoints return a 402 Payment Required error identifying the resource, current count, and limit. Agents and configs you already have keep running, but you can't add more until you upgrade to Enterprise or remove existing ones.

How do I get pricing for a Telegraf Enterprise license?

Enterprise licenses aren't self-serve or listed at a fixed price. To purchase a Telegraf Enterprise license, you contact InfluxData, and the exact configuration and agent limits you receive are defined in your license as part of that contract, rather than a fixed tier.

How is a Telegraf Enterprise license applied once purchased?

You apply the license to Telegraf Controller using the LICENSE_FILE_PATH environment variable at startup, or by uploading the license file directly through the Controller UI. No separate installation is needed; just add the license file to your existing deployment.

Is Telegraf Controller the same thing as the previously available Telegraf Controller beta?

Yes, but Telegraf Enterprise license unlocks higher-scale limits, audit logging, LDAP/OIDC integration, and commercial support.

Why Relational Databases Fail Satellite Telemetry

Allyson Boate (InfluxData) — Fri, 19 Jun 2026 08:00:00 +0000

Satellite operations depend on telemetry as the primary interface to systems that teams cannot directly inspect. Once a spacecraft reaches orbit, signals such as battery levels, temperature, signal strength, and fault codes become the foundation for understanding system health and maintaining control.

Telemetry streams continuously, so the underlying data system becomes a critical control point that needs to handle a constant, heavy flow of data. When that system cannot ingest, query, and manage data efficiently, dashboards lag, investigations slow, and the clarity teams rely on begins to erode.

Relational data vs. satellite telemetry

Relational data organizes information into structured records with consistent fields and defined relationships. A business application might represent customers, orders, and products as related datasets, making it easy to answer questions such as which customer placed an order or which products were included in a purchase. This relational model works well when information is relatively stable and relationships between records are clearly defined.

Satellites are dynamic systems. Operators are not tracking static records or one-time transactions, but monitoring systems that change continuously. Telemetry arrives as a stream of time-stamped measurements, or time series data. Each value depends on when the system recorded it and its change relative to earlier readings.

A single battery reading of 80% may appear normal. In isolation, it provides limited insight. If that value declined from 95% over the past hour, the same reading indicates a different condition. Operators need the sequence, rate of change, and surrounding context to determine whether a change reflects normal behavior, an emerging anomaly, or a sign of impending failure.

As telemetry volume grows, individual readings lose meaning without historical continuity. Teams need to understand how values change over time, not just what they are at one moment. As that requirement grows, relational systems show their limits.

Where relational databases start to strain

PostgreSQL- and MySQL-style databases can support early telemetry workloads, especially when teams already use them for operational data. The strain begins when a transactional, row-oriented database becomes the primary store for high-volume telemetry.

For these systems, telemetry challenges typically appear in three areas: query speed, data lifecycle management, and storage efficiency.

Speed and Query Performance

Satellite operations rely on dashboards, alerts, and analytics to maintain visibility into system health. When a subsystem begins overheating or signal strength drops during a contact window, teams need recent data immediately.

Relational databases such as PostgreSQL and MySQL can store telemetry, but they don’t optimize for high-volume time series workloads. As measurements accumulate, queries must process larger datasets, indexes expand, and the database spends more resources balancing continuous writes with analytical reads.

Slow queries affect more than latency. Delayed dashboards and alerts reduce the time teams have to detect anomalies, investigate issues, and make operational decisions. Teams may need additional infrastructure and ongoing tuning to keep systems responsive, increasing the cost of managing mission data.

Time Awareness and Data Lifecycle

Telemetry does not retain the same value over time. Recent measurements are critical for real-time monitoring, anomaly detection, and fault investigation, where operators need full-resolution data. Older data remains useful, but teams more often use it for trend analysis, reporting, and long-term performance evaluation.

PostgreSQL- and MySQL-style transactional databases do not manage this telemetry lifecycle by default. Teams can use partitions, scheduled jobs, archive tables, or custom pipelines to retain, move, or summarize older records, but those processes require separate design, maintenance and governance. Other relational systems handle historical analysis differently. Analytical databases and data warehouses can support large-scale scans and reporting, but continuous telemetry creates separate tradeoffs around ingest speed, data freshness, cost, and operational responsiveness.

For telemetry stores, lifecycle management becomes ongoing operational work. Without a clear strategy, raw measurements continue to accumulate, historical datasets grow harder to manage and queries may process more full-resolution data than operators need for long-term analysis.

Storage and Scale

Satellite telemetry generates large volumes of measurements, many of which share the same contextual information. Spacecraft identifiers, subsystem names, and sensor metadata often repeat across millions of records while only the timestamp and value change.

Telemetry schemas can also become large and sparse as missions add more sensors, subsystems, and measurement types. Not every field applies to every reading, but the database still has to store, index, and manage the growing structure around those measurements. As the number of sources and dimensions increases, data volume grows rapidly, and cardinality expands, multiplying the number of unique series the system must store.

PostgreSQL- and MySQL-style transactional databases are not optimized for this pattern. Row-oriented storage works well when each row represents a distinct transaction or operational record. Telemetry behaves differently. It repeats similar context across continuous streams of time-ordered measurements, which can make compression less efficient and increase storage overhead.

Over time, organizations may allocate more infrastructure simply to retain and manage telemetry. What begins as a manageable archive can become increasingly expensive to maintain, especially when long-term historical data remains important for analysis and mission planning.

These limitations stem from storage models designed for transactional records rather than continuous, time-ordered measurements.

Time series databases: A better fit for time-series data

Time series databases are purpose-built for data that changes over time. Instead of organizing information around static records and relationships, they structure data around timestamps, time ranges, and continuous streams of measurements.

This design matches how satellite telemetry behaves. Operators need to monitor recent readings, compare values across time windows, identify trends, and investigate anomalies using historical context. The database must support both high-ingest workloads and fast access to time-based data.

InfluxDB is a time series database built for these requirements. It provides a data layer optimized for telemetry, helping satellite teams power real-time dashboards, alerts, anomaly detection, and long-term analysis while avoiding many of the performance and scalability challenges that emerge when telemetry is stored in a relational database.

Maintaining Query Speed at Scale

InfluxDB 3 maintains query performance as telemetry volumes grow. Its architecture combines a real-time columnar engine with technologies designed for analytical workloads, helping teams retrieve and analyze large datasets efficiently.

Telemetry is stored in a columnar format, allowing queries to read only the fields they need instead of scanning entire records. Because data is organized around time, queries can focus on relevant time ranges rather than searching across the full dataset.

InfluxDB 3 also uses Apache DataFusion to power SQL queries. DataFusion applies filters early and processes data efficiently through batches, reducing the amount of information that must be scanned and moved during query execution.

For satellite operations, these optimizations help keep dashboards, alerts, and investigations responsive even as telemetry volumes increase. Teams can access recent measurements and historical trends without the growing query overhead that often affects relational systems handling large-scale time series data.

Managing Data Over Time

Telemetry does not retain the same value over time. Recent measurements are critical for real-time monitoring, anomaly detection, and fault investigation, where operators need full-resolution data. Older telemetry remains useful, but teams more often use it for trend analysis, reporting, and long-term performance evaluation.

InfluxDB supports this lifecycle through retention and downsampling. Retention policies define how long data remains available, while downsampling converts older high-frequency telemetry into lower-resolution aggregates that preserve long-term trends.

This approach helps teams manage telemetry according to how it’s actually used. Recent data can remain detailed and readily accessible for operational workflows, while historical data can be summarized to reduce storage requirements and query costs.

By automating retention and downsampling, InfluxDB reduces the need for custom cleanup scripts, archive processes, and manual data management. Teams can spend less time maintaining telemetry pipelines while keeping storage growth and query overhead under control.

Reducing Storage Overhead at Scale

Telemetry adds both fresh and repeated data. As missions add sensors, measurement types, and metadata, telemetry schemas can become large, sparse, and expensive to store. InfluxDB 3 organizes telemetry in a columnar format built on Apache Arrow and Apache Parquet, which helps store similar values together and improve compression.

This matters for satellite workloads. Spacecraft, subsystem, and sensor labels may repeat across large volumes of readings, while different measurements may rely on different fields. A storage model designed for time series data can compress repeated values and sparse data more efficiently than a transactional model that treats each reading like a separate record.

Stronger compression helps reduce storage overhead as telemetry volume and cardinality grow, allowing teams to retain historical context without carrying the full storage cost of every raw measurement, repeated label, and unused field. InfluxDB 3 also supports architectures that separate compute from storage, giving organizations more flexibility to scale storage and query resources independently as data grows.

It’s a model that helps slow the growth of storage overhead: satellite teams can keep more telemetry available for analysis while reducing the infrastructure cost of storing large, repetitive telemetry datasets.

Processing telemetry beyond storage

The value of satellite telemetry lies in understanding and responding to real-time spacecraft behavior. Operational impact comes from turning continuous streams of measurements into timely insights that help teams maintain visibility and make informed decisions with confidence.

InfluxDB is the foundation that makes that possible. By combining scalable telemetry storage with built-in processing capabilities, it helps satellite teams support real-time monitoring, accelerate analysis, and automate workflows that keep mission operations running smoothly.

Whether the goal is improving spacecraft health monitoring, reducing investigation time, scaling telemetry infrastructure, or preserving long-term mission insight, InfluxDB helps transform telemetry data into a continuous source of operational value.

2Get started with InfluxDB 3 Core OSS or InfluxDB 3 Enterprise to build a telemetry platform designed for time series workloads.

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.

FAQ

What is the --use-pacha-tree flag, and what does it actually change under the hood?

The flag opts into a broader storage layer upgrade that introduces a new columnar file format (.pt files), automatic Parquet migration with hybrid query mode, column families for efficient wide-table I/O, and bounded compaction. This means enabling it changes how data is physically stored on disk, not just which API features are exposed, which is part of why it remains opt-in rather than default in 3.10.

Are the new backup/restore, row-level delete, and bulk import features exclusive to Enterprise, or do they also work in Core?

These capabilities are exclusive to Enterprise; row-level deletion, backup and restore, and bulk import all require the performance update preview and are not available in Core.

Is the performance beta storage format compatible with older InfluxDB 3 versions, or is upgrading a one-way move?

Catalog upgrades in this generation are one-directional and happen when upgrading to InfluxDB 3.10. After migration, 3.9.x and older binaries are unable to read the new catalog and fail to start on the same cluster data. Teams should back up before upgrading and treat enabling the beta (or later upgrading to newer releases) as a forward-only move for a given cluster.

How does the RBAC preview's JWT-based login differ from InfluxDB's existing token authentication?

Existing token workflows will continue to work exactly as they do today, meaning the new username/password and OAuth/OIDC login options are additive rather than a replacement. The new system layers session-based, role-scoped access (Admin, Auditor, Member) on top of the existing static API token model, giving teams a path toward user-level accountability without forcing an immediate migration away from token-based automation.

Does the new /ready endpoint replace existing health check endpoints, or supplement them?

The/ready endpoint focuses on traffic-routing accuracy: verifying that a node can actually serve traffic, not just whether a process is running, by checking connectivity to the object store. It's meant to supplement rather than replace basic liveness/uptime checks.

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.