InfluxData Blog - Charles Mahler

Building a Predictive Maintenance Plugin with the InfluxDB 3 Processing Engine

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

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

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

What we’re building

Here’s the architecture at a glance:

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

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

Prerequisites

Before starting, make sure you have:

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

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

Install InfluxDB 3 Core

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

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

When the script finishes, confirm it worked:

influxdb3 --version

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

Docker

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

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

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

Start InfluxDB with the Processing Engine enabled

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

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

mkdir -p ~/influxdb3/plugins

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

A few notes on these flags:

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

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

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

Create an admin token

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

influxdb3 create token --admin

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

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

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

Create a database

Create a database to hold our data:

influxdb3 create database engine_fleet

Verify it exists:

influxdb3 show databases

You should see engine_fleet in the list.

Load the dataset into InfluxDB

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

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

pip install influxdb3-python pandas

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

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

import pandas as pd
from influxdb_client_3 import InfluxDBClient3, Point

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

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

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

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

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

points = []
BATCH = 5000

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

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

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

if points:
    client.write(points)

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

Run it:

python load_cmapss.py

A few design choices worth calling out:

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

Confirm the data landed:

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

An overview of the plugin model

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

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

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

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

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

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

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

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

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

Predictive maintenance plugin logic

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

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

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

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

Creating the plugin

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

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

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

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

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

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

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

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

    if not healthy_rows or not degraded_rows:
        return None

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Let’s walk through the important parts.

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

Creating the trigger

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

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

Breaking that down:

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

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

Testing out the plugin

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

The latest RUL estimates, most-degraded first:

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

The maintenance alerts:

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

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

influxdb3 show plugins

And the engines flagged critical right now:

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

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

Inspecting logs and iterating

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

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

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

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

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

To pause the system without deleting anything:

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

Error Handling

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

What to build next

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

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

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

How to Use Time Series Autoregression (With Examples)

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

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

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

Understanding time series autoregression

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

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

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

Where:

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

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

Types of autoregressive models and their applications

AR(1) First-Order Autoregression

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

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

AR(p) Higher-Order Models

More complex temporal patterns often require multiple lags:

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

Seasonal Autoregressive Models

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

Model Selection and Diagnostic Considerations

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

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

Setting up your environment

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

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

Installing Required Libraries

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

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

python -m venv .venv

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

source .venv/bin/activate

For Window run this:

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

And finally, install the required libraries:

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

Connecting to InfluxDB

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

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

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

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

Implementing AR models for predicting temperature

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

Loading and Preprocessing the Data

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

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

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

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

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

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

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

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

Exploring Autocorrelation and Determining Model Order

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

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

Building and Training the AR Model

Now let’s implement the autoregressive model:

Visualization is crucial for understanding model performance:

Benefits and limitations of autoregressive models

Advantages of AR Models

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

Limitations and Challenges

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

Practical Implementation Considerations

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

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

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

Time series analysis with InfluxDB

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

Optimized Storage and Performance

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

Real-time Data Processing

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

Scalable Query Operations

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

Native Time Series Functions

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

Production deployment and best practices

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

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

Capping it off

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

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

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

What is MRO? Maintenance, Repair, and Operations Explained

Charles Mahler (InfluxData) — Tue, 31 Mar 2026 08:00:00 +0000

MRO stands for maintenance, repair, and operations. It refers to the activities, supplies, and services that keep equipment, facilities, and infrastructure running safely and efficiently. Every industry that relies on physical assets depends on MRO, whether that means replacing a worn bearing on a production line, restocking safety gloves in a warehouse, or servicing an HVAC system in a hospital.

Despite being one of the largest categories of indirect spending in most organizations, MRO is chronically under-managed. This article explains what MRO covers, why it matters, how maintenance strategies differ, and how it plays out across industries.

What is MRO?

MRO is a broad category that encompasses the indirect materials, maintenance activities, and operational support required to keep a business functioning. MRO includes everything from spare parts and lubricants to safety equipment, cleaning supplies, and the labor required to inspect, fix, and service physical assets.

The scope of MRO varies by organization, but it always sits outside of direct production. A replacement motor for a conveyor belt is an MRO item. The raw steel that travels on that conveyor is not. This distinction matters for accounting, procurement strategy, and inventory management.

Common MRO Supplies and Activities

MRO is easier to understand through concrete examples:

Category	Description	Examples
MRO supplies	Parts, materials, and consumables used to maintain equipment and facilities.	Spare parts (bearings, seals, belts, filters, motors), lubricants and greases, fasteners, hand and power tools, electrical components (fuses, contactors, wiring), safety equipment (gloves, goggles, hard hats, respirators), cleaning and janitorial products, adhesives and tapes, and facility consumables (light bulbs, HVAC filters).
MRO activities	Hands-on maintenance and repair work performed on assets.	Routine inspections, lubrication, electrical testing, equipment alignment, welding repairs, painting and corrosion protection, calibration, and full equipment rebuilds.
MRO services	Outsourced or contracted maintenance support.	Third-party maintenance contracts, on-call repair technicians, specialized inspections (non-destructive testing), and outsourced maintenance for complex assets.

Why MRO matters

MRO spending often accounts for a significant share of an organization’s operating costs, yet it receives a fraction of the strategic attention that direct materials get. The numbers make a compelling case for changing that.

The market is massive. The global MRO market was valued at roughly $715 billion in 2025 and is projected to grow steadily through the next decade, driven by aging infrastructure, the rise of predictive maintenance, and increasing demand for operational efficiency.
Downtime is extraordinarily expensive. A 2024 Siemens report found that unplanned downtime costs the world’s 500 largest companies a combined $1.4 trillion per year, roughly 11% of their annual revenues. At a facility level, costs vary by industry, but the averages are sobering: approximately $260,000 per hour in general manufacturing, and over $2 million per hour in automotive production. Even smaller manufacturers typically lose over $100,000 per hour of unexpected downtime.
Equipment failure is the leading cause of downtime. The average manufacturer faces an estimated 800 hours of equipment downtime annually. Equipment failure accounts for roughly 42% of unplanned downtime incidents, and base components like bearings, seals, and motors are the most common culprits. These are precisely the kinds of failures that a well-run MRO program is designed to prevent.
Proactive maintenance pays for itself. Research from McKinsey and others consistently shows that organizations implementing predictive maintenance programs see 18–25% reductions in overall maintenance costs and 30–50% reductions in unplanned downtime. The U.S. Department of Energy has reported a potential ROI of up to 10x on predictive maintenance investments. Reactive repairs, by contrast, cost three to five times more than planned maintenance once you account for emergency labor, expedited parts shipping, and cascading production losses.
Safety and compliance depend on it. Regulatory bodies across industries mandate specific maintenance activities and intervals. Falling behind on MRO creates safety hazards for workers, compliance risk for the organization, and potential legal liability.

Maintenance strategies: preventive, predictive, planned, and condition-based

Organizations typically employ a mix of strategies, and the trend across industries is a steady shift from reactive to proactive, data-driven approaches.

Preventive Maintenance

Preventive maintenance is scheduled work performed at fixed intervals to reduce the likelihood of failure. Oil changes every 500 operating hours, filter replacements every quarter, and belt inspections every month are all preventive activities. The advantage is predictability: you know what work is coming and can plan parts and labor accordingly. The drawback is that you may be replacing components that still have significant useful life remaining, which wastes money and materials.

Planned Maintenance

Planned maintenance is a broader category that includes any maintenance activity scheduled in advance, whether it follows a calendar-based interval, a usage-based trigger, or a condition-based alert. The defining characteristic is that the work is anticipated and resourced before it begins, as opposed to reactive or emergency maintenance. Planned maintenance also encompasses scheduled shutdowns and turnarounds, where equipment is taken offline deliberately for extensive servicing.

Condition-Based Maintenance

Condition-based maintenance (CBM) uses real-time monitoring of equipment health indicators like vibration, temperature, oil quality, and electrical signatures to trigger maintenance only when those indicators show that maintenance is actually needed. Rather than replacing a bearing on a fixed schedule, CBM replaces it when vibration analysis shows degradation has reached a threshold. This approach eliminates much of the waste inherent in time-based schedules while still catching problems before failure.

Predictive Maintenance

Predictive maintenance takes condition-based monitoring a step further by applying machine learning, statistical models, and trend analysis to forecast when a component is likely to fail. Where CBM reacts to current conditions, predictive maintenance anticipates future conditions based on patterns in historical and real-time data. Sensors tracking vibration, temperature, pressure, and acoustic signatures feed data into analytics platforms that can predict failures days or weeks in advance.

The results are striking: organizations with mature predictive maintenance programs report 35–45% reductions in unplanned downtime and an average ROI of around 250% within the first 18 months.

The movement from reactive to predictive maintenance is one of the defining trends in MRO. As IIoT sensors become cheaper and more accessible, even smaller manufacturers can begin shifting toward condition-based and predictive approaches.

MRO in manufacturing

In the manufacturing industry, MRO encompasses all indirect materials and maintenance activities required to keep a production facility running. It is everything that supports the production process without becoming part of the finished product.

Manufacturing MRO spending is often highly fragmented. A single plant might purchase thousands of distinct SKUs, such as motor drives, conveyor belts, lubricants, rags, and safety boots, from dozens of suppliers. The proportion of organizations using more than 250 MRO suppliers has grown from 6% to 15% in recent years. This fragmentation makes it difficult to negotiate volume discounts, track usage, or identify waste.

Common MRO priorities in manufacturing include reducing unplanned downtime on production lines, maintaining critical spares inventory for high-impact equipment, shifting from reactive to preventive or predictive maintenance, standardizing parts and suppliers to simplify procurement, and ensuring compliance with OSHA and environmental regulations.

Manufacturers that invest in structured MRO programs typically see improvements in overall equipment effectiveness (OEE), lower maintenance costs per unit of output, and fewer safety incidents.

MRO in aviation

Aviation has one of the most rigorous and regulated MRO environments of any industry. Aircraft MRO is governed by strict regulatory frameworks like the FAA in the United States and EASA in Europe. Every maintenance activity must be performed by certified repair stations, documented in detail, and traceable.

The four main categories of aviation MRO are airframe maintenance, engine maintenance, component maintenance, and line maintenance.

Aviation MRO is also where data-driven maintenance has seen some of its most advanced applications. Airlines use predictive maintenance platforms that analyze sensor data from aircraft systems to forecast component failures before they occur, minimizing aircraft-on-ground events and improving safety.

MRO in energy and utilities

Energy and utilities represent one of the most asset-intensive sectors for MRO. Power plants, refineries, pipelines, water treatment facilities, and electrical grids all require continuous maintenance to remain operational and safe.

The consequences of downtime in energy are particularly severe. Utilities face additional complexity from regulatory oversight and public safety requirements; a failed transformer or water treatment system affects entire communities.

This sector has been an early adopter of IIoT and predictive maintenance technologies. Real-time monitoring of turbines, generators, transformers, and pipeline infrastructure allows operators to detect degradation early and schedule maintenance during planned outages rather than responding to emergencies.

MRO procurement, inventory, and software

Three operational areas determine how well an MRO program actually performs on a day-to-day basis.

Area	Description and Key Strategies
Procurement	The process of sourcing and purchasing indirect materials. High transaction volume but low individual dollar value. Improvement strategies include consolidating suppliers, using blanket purchase orders, and implementing e-procurement platforms.
Inventory	Balancing part availability against carrying costs. Effective management relies on criticality-based stocking, min/max levels, and regular cycle counts. MRO inventory supports production but is not part of the finished product.
Software	Tools to plan, track, and optimize maintenance. Includes CMMS for work orders, EAM for lifecycle planning, and e-procurement tools to streamline purchasing.

The process of sourcing and purchasing indirect materials. High transaction volume but low individual dollar value. Improvement strategies include consolidating suppliers, using blanket purchase orders, and implementing e-procurement platforms.

Inventory

Balancing part availability against carrying costs. Effective management relies on criticality-based stocking, min/max levels, and regular cycle counts. MRO inventory supports production but is not part of the finished product.

Software

Tools to plan, track, and optimize maintenance. Includes CMMS for work orders, EAM for lifecycle planning, and e-procurement tools to streamline purchasing.

Where time series databases fit in an MRO strategy

The shift toward predictive maintenance creates a data infrastructure challenge that traditional systems were never designed to handle. A modern manufacturing facility with thousands of IIoT sensors can generate billions of data points daily. This is time series data, and it requires specialized tools at scale.

Traditional relational databases and legacy data historians struggle with the volume, velocity, and query patterns of high-frequency sensor data. Time series databases are built for this workload. They are designed to ingest large volumes of timestamped data at high speed, compress it efficiently for long-term storage, and support the kinds of queries that maintenance and operations teams actually need: trend analysis over time windows, anomaly detection, and correlation across multiple sensor streams.

InfluxDB is one of the most widely adopted time series databases in industrial environments. It is built to handle the data patterns that MRO and predictive maintenance generate, and it fits into the maintenance technology stack in several important ways.

Real-time equipment monitoring: InfluxDB ingests data from PLCs, SCADA systems, and IIoT sensors via standard industrial protocols like MQTT, OPC UA, and Modbus through its Telegraf agent. This creates a live feed of equipment health data that maintenance teams can use to spot anomalies as they develop.
Historical context for predictive models: Effective predictive maintenance depends on having deep historical data to train machine learning models. InfluxDB stores years of sensor data in a compressed columnar format, making it practical and cost-effective to retain the historical depth that ML models need to identify failure patterns.
Bridging OT and IT systems: One of the persistent challenges in MRO is that operational technology and information technology often exist in separate silos. InfluxDB integrates with both sides of this divide, connecting industrial data sources at the edge with analytics tools, cloud platforms, and AI/ML pipelines on the IT side.
Edge-to-cloud flexibility: Not every facility has the same infrastructure. Some need on-premises data processing for latency or security reasons; others want cloud-based analytics. InfluxDB supports deployment at the edge, in private clouds, or in fully-managed cloud environments, allowing organizations to match their data architecture to their operational reality.

The practical impact is tangible. Seadrill has reported saving over $1.6 million in a single year by using InfluxDB as its time series database for equipment monitoring. Siemens Energy uses InfluxDB to monitor 23,000 battery modules across more than 70 sites, analyzing billions of sensor readings to prevent downtime and ensure quality.

For operations and maintenance teams evaluating their data infrastructure, the key question is whether their current systems can handle the data volumes that condition-based and predictive maintenance demand. If the answer is no, a time series database is the foundational layer that makes advanced maintenance strategies possible.

Common MRO challenges

Even well-intentioned MRO programs run into recurring problems.

Fragmented Spending

This is the most widespread issue. When every department or site purchases MRO supplies independently, organizations lose leverage with suppliers and have no visibility into total spend.

Reactive Maintenance Culture

This culture remains entrenched in many organizations. ABB’s Value of Reliability research found that two-thirds of companies experience unplanned downtime at least once per month, and a full third have not undertaken motor or drive modernization projects in the past two years, even though upgrading obsolete equipment can generate ROI in less than two years.

Poor Data Quality

Poor data quality undermines almost every MRO improvement effort. Incomplete asset records, mislabeled parts, and patchy work-order histories make it difficult to decide what to stock, when to maintain, and where to invest. This problem compounds as organizations try to implement predictive maintenance, which depends entirely on clean, structured, time-stamped data.

Excess and Obsolete Inventory

Excess and obsolete inventory tie up capital and warehouse space. Parts ordered for equipment that has since been retired, or spares stocked based on outdated failure rates, accumulate quietly until someone audits the stockroom.

How to improve an MRO strategy

There is no single playbook for MRO improvement, but a few principles apply broadly.

Start with visibility. Before you optimize anything, you need a clear picture of what you are spending, where your inventory sits, and how your assets are performing. Consolidating data from procurement, maintenance, and inventory systems is almost always the first step.
Classify assets by criticality. Not all equipment deserves the same level of attention. Focus preventive and predictive maintenance resources on the assets whose failure would cause the greatest impact on safety, production, or cost.
Consolidate suppliers and standardize parts. Reducing the number of MRO suppliers simplifies procurement, improves negotiating leverage, and makes it easier to manage inventory. Standardizing on common parts across similar equipment reduces the total number of SKUs you need to carry.
Shift from reactive to proactive maintenance. This is a long-term cultural change, not a one-time project. Start with the highest-criticality assets, prove the value with condition monitoring and predictive analytics, and then scale. Organizations that make this transition consistently report dramatic reductions in both downtime and total maintenance cost.
Invest in the right data infrastructure. Advanced maintenance strategies are only as good as the data infrastructure behind them. This means CMMS/EAM software for work order management, time series databases for high-frequency sensor data, and integration layers that connect these systems so that insights flow from the sensor to the decision-maker without friction.
Measure what matters. Track metrics that connect MRO performance to business outcomes: planned vs. unplanned maintenance ratio, spare parts availability, mean time between failures (MTBF), overall equipment effectiveness (OEE), and maintenance cost as a percentage of asset replacement value.

Wrapping up

MRO may not be the most glamorous line item in an operating budget, but it is one of the most consequential. The organizations that treat maintenance, repair, and operations as a strategic function consistently outperform those that don’t. As sensor technology gets cheaper, predictive analytics gets smarter, and the data infrastructure to support them becomes more accessible, the gap between reactive and proactive organizations will only widen. The best time to invest in your MRO strategy was five years ago. The second-best time is now.

MRO FAQs

What does MRO stand for?

MRO most commonly stands for maintenance, repair, and operations—the activities, supplies, and services that keep equipment and facilities running. In aviation and heavy industry, MRO can also stand for maintenance, repair, and overhaul, where "overhaul" refers to the complete teardown, inspection, and rebuild of a component or system to original specifications. Both meanings describe the same core concept: sustaining operational readiness of physical assets.

What is MRO in business?

In a business context, MRO refers to all indirect spending related to keeping operations running. This includes everything from preventive maintenance schedules and spare parts to safety equipment, cleaning supplies, and facility consumables. MRO sits outside of direct production costs but has a significant impact on uptime, safety, and total operating expense.

What is the difference between MRO inventory and production inventory?

Production inventory consists of raw materials and components that become part of the finished product. MRO inventory includes spare parts, tools, consumables, and supplies used to maintain equipment and facilities; items that support production but never appear in the final product. Both require management, but they serve different purposes and are often handled by different teams with different procurement strategies.

What is MRO in manufacturing?

In manufacturing, MRO covers the indirect materials (lubricants, filters, PPE, tools, electrical components) and maintenance activities (inspections, repairs, preventive maintenance) required to keep production equipment operational. It is one of the largest categories of indirect spending in most manufacturing organizations.

What is MRO in aviation?

In aviation, MRO stands for maintenance, repair, and overhaul. It is a heavily regulated segment that includes line maintenance, airframe and engine maintenance, component repair, and full overhauls of aircraft systems. Aviation MRO is essential for airworthiness certification and passenger safety, and it is governed by regulatory bodies like the FAA and EASA.

What are MRO supplies?

MRO supplies are the materials purchased to support maintenance and operational activities. Common examples include spare parts, fasteners, lubricants, hand tools, safety gear, cleaning products, electrical components, and facility consumables like light bulbs and HVAC filters. These items are consumed during the maintenance process rather than incorporated into a finished product.

Why is MRO important?

MRO directly affects equipment uptime, workplace safety, regulatory compliance, and operating costs. Unplanned downtime alone costs U.S. manufacturers an estimated $50 billion per year. Organizations that manage MRO effectively experience fewer breakdowns, lower total maintenance costs, longer asset lifespans, and better safety records. As maintenance strategies evolve from reactive to predictive, the strategic importance of MRO continues to grow.

What is the difference between preventive and predictive maintenance?

Preventive maintenance follows a fixed schedule. For example, replacing a filter every 90 days regardless of its condition. Predictive maintenance uses real-time data from sensors to forecast when maintenance is actually needed, based on the condition and performance trends of the equipment. Predictive approaches reduce both unnecessary maintenance and unexpected failures, but they require investment in sensors, data infrastructure, and analytics tools.

What is a CMMS and how does it relate to MRO?

A CMMS (computerized maintenance management system) is software used to schedule, track, and document maintenance activities. It is one of the core tools in an MRO program, helping teams manage work orders, track asset history, plan preventive maintenance schedules, and monitor spare parts inventory. More advanced platforms (often called EAM, or enterprise asset management systems) add lifecycle planning, capital project tracking, and integration with other enterprise systems.

A Practical Guide to SCADA Security

Charles Mahler (InfluxData) — Tue, 03 Mar 2026 08:00:00 +0000

Critical infrastructure is under siege. The systems that control our power grids, water treatment plants, and oil pipelines weren’t designed for a connected world. This post covers what security measures teams need to understand and how time series monitoring can help turn SCADA’s weaknesses into a security advantage.

The stakes for SCADA security have never been higher

Somewhere right now, a programmable logic controller is opening a valve, adjusting a turbine’s speed, or regulating the chlorine levels in a city’s drinking water. These actions are orchestrated by Supervisory Control and Data Acquisition (SCADA) systems. They run power grids, water treatment facilities, oil and gas pipelines, manufacturing plants, and transportation networks.

For decades, these systems operated in relative obscurity. They sat on isolated networks, spoke proprietary protocols, and were managed by operational technology (OT) engineers who rarely crossed paths with the IT security team.

The convergence of IT and OT networks, driven by the demand for remote access, operational analytics, and cost efficiency, has dragged SCADA systems into a threat landscape they were never built to survive. The results have been dramatic. In 2015 and 2016, coordinated cyberattacks took down portions of Ukraine’s power grid, leaving hundreds of thousands without electricity. In 2021, the Colonial Pipeline ransomware attack shut down fuel distribution across the U.S. East Coast, triggering panic buying and fuel shortages.

These aren’t theoretical risks. They’re documented events, and they only represent the incidents that became public. The reality is that SCADA systems are being probed, scanned, and targeted every day, and many operators lack the visibility to even know it’s happening.

SCADA security challenges

Securing SCADA and industrial control systems is fundamentally different from securing a corporate IT environment. The assumptions, priorities, and constraints are almost inverted.

Availability Over Confidentiality

In IT security, the classic triad is confidentiality, integrity, and availability, usually prioritized in roughly that order. In OT, the priorities flip. A power plant cannot tolerate downtime. A water treatment facility cannot go offline for a patch cycle. The consequences of a disrupted industrial process aren’t a lost spreadsheet; they’re potential physical harm, environmental damage, or loss of life. This means that many standard IT security practices, such as aggressive patching, frequent reboots, and network scanning, can be dangerous or even impossible in OT environments.

Legacy Systems and Long Lifecycles

SCADA components often have operational lifecycles of 20 to 30 years. It’s not uncommon to find PLCs running firmware from the early 2000s, human-machine interfaces (HMIs) on Windows XP, or historians on unsupported database platforms. These systems were engineered for reliability and determinism, not security. Replacing them is expensive and operationally risky, so they persist despite the vulnerabilities.

Protocols Without Security

Modbus, DNP3, and OPC Classic are the workhorses of industrial communication, but they were designed in an era when network isolation was considered sufficient protection. Modbus, for instance, has no authentication, no encryption, and no way to verify the identity of a device sending commands. These protocols are deeply embedded in operational infrastructure and cannot be easily replaced.

The Air Gap Myth

Many organizations still believe their OT networks are air-gapped. In practice, true air gaps are rare. Remote access solutions, vendor support connections, shared file servers, USB drives, and even cellular modems on RTUs create pathways between networks.

Key strategies for SCADA security

Effective SCADA security is layered, OT-aware, and built around the operational realities of industrial environments. There is no single solution, but a combination of strategies dramatically reduces risk.

Network Segmentation

The foundation of SCADA security is proper network architecture. At a minimum, there should be a demilitarized zone (DMZ) between the corporate IT network and the OT network, with no direct traffic flowing between them. Within the OT network, further segmentation between supervisory systems, control systems, and field devices helps limit lateral movement.

Asset Inventory and Visibility

You cannot protect what you don’t know exists. Many organizations lack a complete, accurate inventory of their OT assets, including PLCs, RTUs, HMIs, historians, network switches, and communication links. Passive network discovery tools designed for OT environments can build and maintain this inventory without disrupting operations.

Access Control and Authentication

Every access point into the OT environment should require strong authentication, ideally multi-factor. Least-privilege principles should govern who can access what, and remote access should be tightly controlled, monitored, and time-limited. Shared accounts should be eliminated wherever possible.

OT-Aware Patch Management

Patching in OT requires a risk-based approach. Not every vulnerability needs an immediate patch, and not every system can be patched without operational impact. Organizations need a process that evaluates vulnerability severity in the context of their specific environment, tests patches in a staging environment where possible, and schedules maintenance windows that align with operational needs.

Deep Packet Inspection for Industrial Protocols

Traditional firewalls see Modbus traffic as TCP on port 502 and nothing more. OT-aware firewalls and intrusion detection systems can parse the actual protocol content to inspect function codes and register addresses to enforce policies.

Incident Response Planning

OT incident response is not IT incident response, the playbook must account for the physical consequences of containment actions. Isolating a network segment might stop an attacker, but could also trip a safety system or halt a process. Response plans need to be developed collaboratively between security teams, OT engineers, and plant operations.

Continuous monitoring for SCADA security

All of the strategies above are essential, but there’s a fundamental truth about SCADA security that defenders can exploit: industrial processes are inherently predictable.

A temperature sensor in a chemical reactor reports a value every second. A PLC cycles through its logic on a fixed schedule. A pump runs at a consistent speed. Network traffic between a SCADA server and its RTUs follows regular, repeatable patterns. This predictability means that anomalies like equipment failure, operator error, or a cyberattack create detectable deviations from established baselines.

This is where time series data becomes a security team’s most powerful tool.

Baselining Normal Behavior

By collecting and storing high-resolution time series data from sensors, PLCs, network flows, and protocol logs, you can build a detailed behavioral profile of “normal” for every asset and process in your environment. What does normal Modbus traffic look like between the SCADA server and PLC-07? What’s the typical temperature range for reactor vessel 3 during a batch run? How often does the engineering workstation initiate write commands?

With enough historical data, these baselines become remarkably precise, and deviations become immediately apparent.

Detecting Process Manipulation

An attacker who gains access to a SCADA system may try to subtly alter process parameters, such as changing a setpoint, opening a valve, or adjusting a chemical dosing rate. If you’re monitoring time series data from those processes, you can detect changes that fall outside historical norms.

Spotting Anomalous Network Behavior

Industrial network traffic is highly structured. By logging protocol-level metadata, you can detect unusual patterns. A “write multiple registers” command from an IP address that has only ever issued read commands is suspicious. A burst of DNP3 unsolicited responses at an unusual time deserves investigation. These signals are only visible if you’re capturing and analyzing this data.

Correlating Across IT and OT

The most sophisticated attacks traverse the IT/OT boundary. Detecting them requires correlating events across both domains on a unified timeline. For example, a failed VPN login attempt at 1:47 AM, followed by a successful login at 1:52 AM, followed by an unusual engineering workstation session at 1:55 AM, followed by a PLC configuration change at 2:03 AM. While each of these events in isolation might not trigger an alert, together, on a single timeline, the pattern is unmistakable. Time series data makes this correlation possible.

Why a time series database beats a SIEM or relational database for OT security data

If you’re convinced that this kind of monitoring is critical for SCADA security, the next question is where to store and analyze all this data. The three common options are a traditional relational database, a Security Information and Event Management (SIEM) platform, or a time series database like InfluxDB. For OT security data, the time series database wins decisively. Here’s why.

Data Volume

A single SCADA environment can generate enormous volumes of data. Consider a modest facility with 500 sensors reporting every second, 20 PLCs, a network tap capturing protocol metadata, and authentication logs from access points. That’s easily millions of data points per day, and larger environments generate orders of magnitude more.

Relational databases like PostgreSQL or MySQL were designed for transactional workloads: inserts, updates, deletes, and joins across normalized tables. They handle time series data poorly at scale. Write throughput degrades as tables grow, and time-based queries over millions of rows become expensive without careful indexing and partitioning, which creates operational complexity. SIEMs are built for log ingestion, but they’re optimized for text-based event logs, not numerical telemetry. Ingesting raw sensor data at one-second intervals into a SIEM is technically possible, but economically painful, as SIEM licensing is typically based on data volume, and the cost of ingesting OT data can be prohibitive. Many organizations end up sampling or aggregating data before it reaches the SIEM, losing the granularity needed for effective anomaly detection.

InfluxDB and other time series databases are built for this workload. They use storage engines optimized for high-volume writes of timestamped data and compressed, columnar storage that keeps disk usage manageable even at scale. InfluxDB can handle hundreds of thousands of writes per second on modest hardware.

Query Performance

OT security analysis is fundamentally time-focused. You need to answer questions like: “What was the average pressure in vessel 4 between 2:00 and 2:15 AM?” or “Show me all Modbus write commands to PLC-12 in the last 24 hours alongside the corresponding sensor readings.” or “Alert me if the rate of change of this temperature exceeds the 99th percentile of its 30-day historical distribution.”

In a relational database, these queries require careful SQL with window functions, CTEs, and often materialized views to perform well. The query language wasn’t designed for time series operations, and performance tuning is an ongoing burden.

SIEMs offer search languages that handle event correlation well but are awkward for continuous numerical analysis. Calculating rolling averages, derivatives, or statistical distributions over sensor data in a SIEM is possible but cumbersome.

Time series databases provide native query primitives for exactly these operations. InfluxDB includes built-in functions for windowed aggregation, moving averages, derivatives, percentiles, and histogram analysis. A query that would require 30 lines of carefully optimized SQL can often be expressed in a few lines with InfluxDB. This matters not just for convenience but for enabling security analysts and OT engineers to explore data and build detection logic without being database specialists.

Data Retention

OT security data has a natural tiered value structure. The last 24 hours of raw sensor data are extremely valuable for investigating an active incident. The last 30 days at full resolution are important for anomaly detection baselines. Data from six months ago is useful for trend analysis, but doesn’t need high granularity. Data from a year ago might only need hourly averages for compliance purposes.

Relational databases require you to manage this lifecycle manually by writing ETL jobs to downsample old data, archive tables, and manage storage. SIEMs typically offer hot/warm/cold storage tiers, but with limited control over how data is aggregated as it ages. InfluxDB has retention policies and downsampling built into the database itself. You can define policies that automatically downsample data from one-second to one-minute resolution after 30 days, then to five-minute resolution after 90 days, and delete raw data after a year. This happens transparently, without external tooling, and keeps storage costs predictable while preserving long-term visibility.

Moving forward

SCADA security is not a problem that can be solved with a single product, a one-time assessment, or a policy document. It requires sustained commitment to understanding your environment, monitoring it continuously, and building the organizational capacity to detect and respond to threats.

The good news is that the same characteristic that makes SCADA systems vulnerable, like their reliance on predictable, deterministic processes, is also what makes them uniquely defensible through data-driven monitoring. Industrial processes generate time series data that reveals anomalies clearly when you have the right tools to capture and analyze it.

A time series database like InfluxDB, paired with a well-designed collection pipeline and visualization layer, enables security teams to see their OT environment with a level of clarity that was previously impractical. Not as a replacement for network segmentation, access control, and the other foundational security measures, but as the monitoring layer that ties everything together and ensures that when something goes wrong, you know about it in seconds rather than weeks.

How Aerospace Companies Use InfluxDB

Charles Mahler (InfluxData) — Fri, 12 Dec 2025 08:00:00 +0000

Over the past two decades, we’ve witnessed the instrumentation of virtually everything in the aerospace industry, from manufacturing floors to satellites orbiting Earth. And it’s no longer just NASA and other government organizations leading the charge. The commercial space industry has grown exponentially, with private companies developing everything from GPS satellites to electric VTOL aircraft.

This proliferation of sensors has transformed time series data from an afterthought into a first-class citizen. Companies store more and more data with higher granularity to become more efficient and reliable. Every component, every operation, and every mission generates massive volumes of time-stamped data that must be captured, analyzed, and acted upon in real-time.

Time series data across the aerospace industry

Time series data is critical in the aerospace industry to ensure safety and efficiency from the factory floor to flight operations. One InfluxDB customer has over 100,000 sensors on their factory floor—a single flight test can create billions of data points, and a 60-90 minute commercial flight generates 400-500 terabytes of data. Many aerospace companies are finding that the traditional data historians or relational databases they have used in the past aren’t viable for these workloads.

InfluxDB is an increasingly popular option for aerospace companies due to its performance, ease of deploying hybrid architectures, and developer experience. Here are a few examples of the benefits seen by developers who migrated to InfluxDB:

The ability to perform real-time monitoring and anomaly detection, upgrading from queries that took up to 30 minutes with their prior database to only seconds with InfluxDB.
Queries that analyze flight test data dropped from 15 minutes to seconds using InfluxDB.
The ability to store data for years instead of weeks at the same cost or less.
Schema-on-write made life easier for developers when working with (potentially) thousands of sensors sending different data.
Built-in functionality for moving data from locally installed InfluxDB instances to the cloud when edge devices have intermittent connectivity.

How aerospace companies use InfluxDB

Thales Space

Thales Space designs and operates satellites that provide a range of services, including telecommunications, navigation, and scientific research. The team uses InfluxDB to process and store their data, and to replay events for analysis. Leveraging InfluxDB enables them to collect and store data with higher granularity, improving the accuracy of the machine learning models used for fault detection and forecasting.

Eutelsat

Eutelsat operates over 600 low-orbit and geostationary orbit satellites. Each of these satellites produces over 50,000 unique telemetry values, and collectively, over 1 million data points per second. Eutelsat initially used Elasticsearch for its telemetry data but faced challenges with write performance, storage costs, and developer experience in transforming telemetry data into a format supported by Elasticsearch.

Eutelsat migrated to using Telegraf for data collecting and InfluxDB for storage. This gives the company unified telemetry data for analyzing spacecraft and ground-side data in a single place. The team uses this data for root-cause analysis by replaying events and proactive alerting. InfluxDB’s performance has also enabled Eutelstat to begin experimenting with machine learning models to improve predictive analytics and has provided more long-term data storage.

Aircraft Manufacturing

A major aircraft manufacturer used InfluxDB to modernize their factory monitoring system. Their existing architecture was built around AVEVA Wonderware and couldn’t keep up with increasing data volume. This setup had the potential to cause million-dollar delays and billions of dollars in losses if manufacturing errors led to airplane defects and regulatory issues.

To achieve their goals, they needed a database that allowed them to monitor each stage of the manufacturing process in real-time. After migrating to InfluxDB, they can track 3,000 different parameters per second from a variety of machines and sensors. InfluxDB also enabled a factory-wide view of their operations and eliminated data silos, creating a single place to track the entire manufacturing process. Another critical factor in choosing InfluxDB beyond performance was its security standards, which met the requirements for both commercial and military customers.

Satellite Communications

A satellite communications provider operating hundreds of satellites needed a new database as they scaled up to over 100,000 metrics per second. Their original solution was a cluster of Postgres instances that was expensive to maintain, operationally intensive to keep running, and had limited query performance, making many types of analysis impossible.

By adopting InfluxDB, engineers and data analysts were able to achieve better performance for both short-term queries required to ensure reliable service and long term queries that scan weeks to months worth of data. Another huge benefit of InfluxDB is the ability to use object storage for long-term data, as industry regulations require the customer to store data for over 10 years.

Looking forward

As the aerospace industry continues to evolve with increasingly sophisticated missions and launch operations, the need for specialized time series databases will only grow. InfluxDB represents a significant step forward compared to legacy solutions, offering the performance, scalability, and developer-friendly features that modern aerospace teams require.

If you are interested in more info about how InfluxDB is used for aerospace, check out this webinar.

9 Tools and Integrations for InfluxDB

Charles Mahler (InfluxData) — Fri, 28 Nov 2025 08:00:00 +0000

InfluxDB is the go-to database for developers working with high-velocity time series data for use cases like application performance monitoring and real-time analytics. But InfluxDB exhibits its true power when combined with the right tools and integrations. The tools covered in this blog post can help at all stages of your workflow, from data collection to visualization and analysis, so you can get the most out of your InfluxDB deployment.

InfluxDB MCP server

The InfluxDB MCP server allows you to integrate InfluxDB 3 with LLMs to query data, inspect your schema, and manage your database using natural language. This makes it easier to work with your data and access it from within the tools you already use.

Microsoft PowerBI

PowerBI Desktop can be used to visualize data stored with InfluxDB by using the Flight SQL ODBC driver. Once connected, you can use PowerBI to build reports, analyze your data with PowerBI’s analytics and AI features, combine your time series data with other data sources, and share these insights across your organization.

Telegraf

Telegraf is a plugin-driven agent that makes it easy to collect and process data before storage. Telegraf has over 300 different plugins for data collection and can output data to InfluxDB and many other databases.

Using Telegraf removes much of the grunt work of collecting data from a variety of sources, allowing you to focus on deriving value from your data. Telegraf makes it easy to automate data ingestion at scale and decouple data collection from storage with minimal dependencies.

InfluxDB 3 Explorer

InfluxDB 3 Explorer is a tool for visualizing, querying, and managing the data stored in your InfluxDB 3 instance. The Explorer has built-in support for querying your data using AI, writing data, and managing processing engine plugins.

Grafana

Grafana is an industry standard for visualizing data and there are multiple ways to integrate Grafana with InfluxDB. The Grafana plugin for InfluxDB makes getting started easy and supports both InfluxQL and SQL for querying your data.

Connecting Grafana to InfluxDB gives you scalable data storage as a foundation for building dynamic visualizations and alerts that allow you to take action on your data. You can correlate metrics, create dashboard templates, and scale as your application grows.

Home Assistant

Home Assistant is a home automation platform that tracks devices, sensors, and state changes across your smart home. The built-in recorder handles day-to-day operations and dashboards, but when you start scaling the number of entities, logging high-frequency sensor data, or keeping months/years of history, you hit limitations in storage efficiency and query performance.

By integrating Home Assistant with InfluxDB, you gain benefits such as the ability to support higher write throughput to support a larger number of sensors and devices with higher-granularity data. You can also perform more advanced analytics to uncover trends and insights as well as optimize your automation workflows.

InfluxDB client libraries

InfluxDB 3 has five officially supported client libraries, which include Python, Java, JavaScript, C#, and Go. These libraries act as wrappers around the InfluxDB HTTP API and provide the following features to improve developer experience:

High performance asynchronous and batch writing
Pandas dataframe support
Rate-limiting

Node-RED

Node-RED is an open source no-code visual programming tool for creating programmatic workflows. Node-RED is often used for home automation, industrial IoT, and general data collection workflows. Data can be collected from sensors, hardware devices, and other sources before it is processed and stored in InfluxDB.

Apache Iceberg

A powerful feature included with InfluxDB is the ability to export data to Apache Iceberg using the Processing Engine. This allows developers to access time series data from tools like Snowflake, Spark, BigQuery, as well as any other tools that support Iceberg. The InfluxDB Iceberg plugin supports scheduled batch transfers at scheduled intervals and on-demand transfers via HTTP requests.

Time to build

InfluxDB’s strength lies not just in providing a high-performance time series database, but in the ecosystem of tools and integrations around it. From AI-powered querying capabilities to data lakehouse bridges, there’s an integration for almost every use case.

Whether you are building IoT applications, monitoring infrastructure, or analyzing business metrics, the integrations and tools covered in this blog post provide the foundation for building powerful, scalable solutions.

The tools covered in this blog post are just a small sample of what you can use with InfluxDB. For more info on the ecosystem of tools available for use with InfluxDB, check out this guide.

Navigating the Database Ecosystem in 2025

Charles Mahler (InfluxData) — Mon, 20 Oct 2025 08:00:00 +0000

In 2025, the database ecosystem is more diverse and interconnected than ever before. From AI-assisted natural language queries that analyze your data to open table formats that make it easy to bridge systems, data infrastructure is moving towards openness, intelligence, and composability. Modern databases are no longer isolated systems; they are part of a broader ecosystem where interoperability is as important as performance.

In this post we’ll explore the state of the database landscape in 2025, the trends to look forward to, the technical tradeoffs to consider when choosing a database, and the different types of databases. If you want even more detail on these topics, be sure to watch the full webinar this post is based on.

2025 database trends

Interoperability

Open formats like Parquet, Arrow, and Iceberg have steadily increased interoperability between databases. This not only makes adopting new technologies easier but also reduces the risk of vendor lock-in for developers. It also allows for zero-copy data sharing across systems and enables OLTP and OLAP data to be combined for improved analytics.

In the early days of NoSQL databases, many of them filled specific niche roles for a particular type of data. In recent years, trends have shifted in the other direction, with databases like Postgres extending to support analytics, vector embeddings, and semi-structured data.

AI-Enhanced Databases

AI is enabling new features at all database levels. At the highest level, LLMs are enabling users to query and analyze data without requiring technical expertise. Tools like the InfluxDB 3 MCP server make it possible to integrate InfluxDB with your favorite AI tools. AI is also being used to do tasks like recommend new indexes or materialized views to improve performance and optimize SQL queries automatically based on performance data. And companies like Google are researching entirely new types of indexes that could replace traditional B-tree indexes, improving performance and reducing storage costs.

What makes databases perform differently?

Every database is a set of engineering tradeoffs. Understanding how these tradeoffs affect performance can help you choose and tune the right system.

Storage Structure

The way a database organizes data on disk fundamentally determines its performance characteristics. Different engines use different data structures to optimize for read latency, write throughput, or a balance between the two. The two most common paradigms are B-trees and log-structured merge-trees (LSM).

B-trees: B-trees are one of the most widely used storage structures in relational databases such as PostgreSQL, MySQL, and SQLite. They organize data hierarchically, storing key-value pairs in sorted order with references to child nodes, keeping the tree balanced as inserts and deletes occur. B-Trees are optimized for random reads and point lookups, but struggle with high write workloads.
LSM-trees: LSM-trees take a radically different approach, designed primarily to optimize write performance. Instead of updating data in place, writes are first appended sequentially to an in-memory structure and then periodically flushed to disk as sorted segments, known as SSTables. Over time, background processes called compactions merge these SSTables to remove duplicates and maintain sorted order. LSM-trees are ideal for workloads involving heavy write volumes but are less efficient for certain types of queries.

Indexing

Indexes accelerate queries but come at a cost. Each index must be updated on write, which can slow down ingestion. The tradeoff can be seen as the choice between query latency vs. write throughput performance.

Storage Format

Another factor in database performance is data organization on disk. The first option is row-oriented storage, which works best for OLTP workloads. The second option is column-oriented storage, which is best for OLAP workloads.

Compression

Compression algorithms like ZSTD or Snappy reduce the storage footprint and I/O overhead by encoding and decoding data. Different compression algorithms have various tradeoffs, the most significant ones being compression ratio, CPU utilization, and latency.

Durability

Another factor in database performance is the durability requirements for your data. If you can’t afford to lose any data, you will take a performance hit by ensuring that all your data is persisted to disk as it is being written and replicated across multiple servers.

How to choose the right database

Selecting the right database for your use case can be as much of a business decision as a technical one. Here are some key factors to take into consideration:

Data Access Patterns

The most important thing to consider is what type of data you will be working with. If you know you will have a write-heavy workload, then you know upfront that you should go with a database designed to support that from the ground up. If you are going to be doing a lot of analytics on your data, you will want to use a database that stores data in a columnar format.

Transactional Requirements

Do you need strict transactions or can your application tolerate eventual consistency? If you don’t need ACID compliance, you can get significant performance benefits from choosing a database that has eventual consistency.

Scalability

Will your volume of data be small enough that simply scaling a server vertically will be sufficient? In that case you can avoid most of the complexity involved with distributed databases.

In-House Knowledge

If your team is already familiar and has expertise operating a specific database, it might be worth choosing that instead of a theoretically superior option that would require your entire team to learn a new tool.

Business Stage

If you are a startup that needs to be able to iterate and move fast, you might see more benefits from a NoSQL database that makes it easy to modify your data model as requirements change.

An overview of different database models


Database Type	Overview
Relational Databases	Structured around predefined schemas and ACID-compliant transactions, relational databases guarantee strong consistency and reliability. They excel at workloads involving complex joins, aggregations, and strict transactional integrity. Ideal for financial systems, ERP platforms, and traditional business applications.
Key-Value Stores	The simplest database model, storing data as key-value pairs. They offer extremely low-latency lookups and are well-suited for caching, session management, and user profile storage. They trade query flexibility for speed and scalability.
Document Databases	Store data in semi-structured JSON-like formats with flexible schemas that adapt as applications evolve. Popular for content management systems, user data, and applications with dynamic or evolving data models.
Time Series Databases	Purpose-built for high-ingest, time-stamped data, such as metrics, logs, and IoT sensor readings. Use optimized storage engines for sequential writes, time-based compression, and downsampling. Excellent for monitoring, observability, and real-time analytics.
Graph Databases	Represent data as nodes and edges, ideal for modeling relationships and networks such as social graphs, recommendation systems, and fraud detection. Use graph traversal algorithms for efficient link and path analysis.
Columnar Databases	Store data by column rather than row, enabling massive scan and aggregation performance ideal for analytical workloads. Often include vectorized execution, advanced compression, and query acceleration for BI and analytics use cases.
In-Memory Databases	Keep most or all data in RAM for microsecond-level latency. Common in real-time analytics, caching layers, and high-frequency trading systems. Trade extreme speed for higher infrastructure cost and volatility management.
Search Databases	Built for full-text, fuzzy, and relevance-based search using inverted indexes and scoring algorithms. Commonly used for log analytics, e-commerce search engines, and application monitoring. Optimized for retrieval speed rather than transactional updates.
Vector Databases	Store and query high-dimensional embeddings generated by ML models. Power semantic search, recommendation engines, and LLM context retrieval (RAG). Optimize for approximate nearest neighbor (ANN) search and hybrid retrieval combining text, metadata, and vectors.
NewSQL Databases	Combine the SQL interface and ACID guarantees of traditional RDBMS with the horizontal scalability of NoSQL systems. Ideal for global-scale transactional applications that demand strong consistency and distributed fault tolerance.

The bottom line

The database ecosystem in 2025 is not about finding one perfect database, it’s about building a composable data architecture. Open formats like Parquet and Iceberg break down silos, while AI copilots unlock intelligent insights. Meanwhile, the fundamentals like storage engines, indexing strategies, and compression still determine raw performance.

The most successful organizations aren’t tied to a single engine. They choose the right tool for each job, blending transactional, analytical, and vector systems into one unified data ecosystem. To continue learning about the modern database ecosystem, be sure to watch the full webinar.

How Nexus BMS Uses Time Series and AI to Power Smarter Buildings

Charles Mahler (InfluxData) — Thu, 25 Sep 2025 08:00:00 +0000

Monitoring equipment isn’t enough for today’s smart buildings; true value comes from being able to predict issues, optimize performance, and take action automatically. Traditional building management systems often fall short, limited to dashboards and alarms that only notify you of an issue after the fact. With the rise of open source hardware, modern databases, and AI-driven diagnostics, facilities can now move from reactive to proactive management.

In this blog, we’ll recap how Nexus BMS leverages InfluxDB, edge controllers, and AI models to not only monitor but also directly control building equipment across diverse environments—from clean rooms to healthcare facilities. For a full walkthrough of the system and its capabilities, be sure to watch the complete webinar.

What is Nexus?

Nexus BMS is a building management system (BMS) designed to replace or complement existing legacy systems. Traditional BMS solutions often stop at monitoring, simply collecting sensor data and displaying it on dashboards. Nexus goes a step further by combining real-time monitoring, direct equipment control, and predictive AI diagnostics into one unified platform.

Nexus is designed to solve real-world problems: broken controllers, rising licensing fees, and facility managers left without reliable tools to operate critical infrastructure. Instead of just alerting when something goes wrong, Nexus continuously processes thousands of sensor readings, applies custom control logic, and can adjust equipment automatically, whether that means fine-tuning a fan coil, modulating a pump, or holding tight tolerances in clean rooms and healthcare environments.

The Nexus platform allows for active control of equipment by providing these features:

Sensor Inputs - Environmental and mechanical data (temperature, humidity, vibration, current draw, etc.) flow from sensors into Raspberry Pi edge controllers.
Logic Execution - Custom control logic, written and stored on the server, determines the correct equipment responses based on live data and user-set thresholds.
Command Generation - Nexus generates control commands—such as adjusting fan coil outputs, changing supply air temperature setpoints, or modulating pumps.
Edge Execution - These commands are sent back to Node-RED workflows or directly executed on the Pi controllers, which then actuate relays, valves, or motors.
User Oversight - Every change is authenticated, logged, and emailed to facility staff for full accountability.

This architecture enables Nexus to detect issues early and take immediate corrective action, ensuring comfort, safety, and efficiency in facilities where environmental control is critical.

Why is time series data needed to power smart buildings?

Smart buildings operate on data, specifically time series data. This is information that is collected, ordered, and stored over time, such as temperature readings, the current draw of a chiller motor, or humidity levels in a clean room. In Nexus BMS, every piece of equipment streams metrics continuously, creating a living dataset that reflects the real-time pulse of a facility.

How Nexus BMS Uses Time Series Data

Time series data is the backbone of Nexus, enabling:

Real-time responsiveness – With new metrics arriving every 15 seconds, the system can instantly detect changes and push control commands to equipment before small fluctuations become big problems.
AI model training – Predictive diagnostics depend on historical patterns. Feeding consistent time series data into Nexus’s seven AI models enables accurate anomaly detection and proactive maintenance.
Fine-grained analysis – Facility managers can slice and query data by device, location, or condition to uncover performance inefficiencies that would otherwise stay hidden.
Trend recognition – Subtle shifts in amp draws, temperature curves, or vibration levels reveal early signs of equipment wear long before alarms are triggered.

Using a time series database like InfluxDB allows Nexus to store high-precision data for longer, saving money and providing users with a better experience due to improved performance compared to general-purpose databases.

Nexus tech stack

Frontend

For the frontend architecture, NextJS provides the framework with ShadCN used for styling. This frontend enables authenticated users to view real-time dashboards, run AI-powered diagnostics with a single click, and manually adjust equipment settings.

Backend

The Nexus backend is a collection of databases that uses NodeJS for programming logic. InfluxDB is at the core of all sensor data utilized in dashboards and model training. Postgres is used for storing configuration as well as AI training records. Redis is also used for caching stateful equipment control data.

Edge Hardware

A number of different hardware devices can deploy Nexus in facilities. Raspberry Pi 5s with 1TB SSDs are used at each site, running Node-RED flows and custom control logic. SQLite databases are installed locally to allow offline operation if network connectivity is lost.

Sequent microsystems boards interface directly with facility equipment, with support for analog and digital signals. Examples of devices include temperature sensors, vibration monitoring systems, and current transducers. Training models utilize Hailo AI accelerator chips.

Next steps

The Nexus BMS story demonstrates what’s possible when real-world expertise meets modern data infrastructure and AI. By combining time series data, open source hardware, and predictive modeling, Nexus transforms building automation from simple monitoring into a proactive, intelligent system that enhances reliability, efficiency, and safety.

If you’re interested in the future of smart building management, be sure to watch the full webinar.

Additional resources

How Cora Uses AI and InfluxDB to Deliver Personalized Health Analytics

Charles Mahler (InfluxData) — Fri, 15 Aug 2025 08:00:00 +0000

Simply collecting and storing data doesn’t create value—the key is being able to derive insights from data to determine what actions to take based on what your data is telling you. In the past, this required specialized knowledge; however, with advancements in AI, we are reaching the point where users don’t necessarily need technical knowledge to derive value from their data.

In this blog, we will go over how the InfluxDB 3 Hackathon winner, Cora, utilizes InfluxDB and LLMs to enable anyone to generate actionable insights based on their own personal health data. For more details, be sure to watch the full webinar.

What is Cora?

Cora is an application that enables users to ingest and analyze data from various health applications, including Fitbit, Oura, and Apple Health, via natural language LLMs. These analyses form the basis of actionable insights for the user’s desired health outcomes, such as improving sleep quality, losing weight, and reducing stress.

Cora is available as a mobile application or with any LLM that can interact with MCP servers, such as Claude.

Why AI needs a time series platform

The features of a platform like Cora aren’t possible with an AI model on its own due to the following problems:

Context window limitations - The large amounts of historical data that need analysis can’t fit into the context window of AI models.
Inability to do math - LLMs are not capable of doing statistical analysis on their own; they need to have access to tools that can do the math for them and then take those answers to respond to the user.

InfluxDB provides the solution by enabling Cora to query data relevant to a user’s query in real-time with minimal latency. On the backend, Cora performs the aggregations and correlations on the data stored in InfluxDB and provides the answers to the LLM, crafting a helpful response to the user’s question about their data. By integrating LLMs with InfluxDB, analytics tools are able to skirt issues with context windows, access external knowledge not in LLM training data, and enable personalized experiences for users. The diagram below illustrates an example of how a user’s interaction with Cora might occur behind the scenes, demonstrating how Cora can interpret questions and perform aggregations and other statistical analyses to provide answers on demand.

Evolution of AI knowledge access

The AI landscape is moving fast, and best practices change rapidly. One of the major challenges when working with AI models is how to give them access to data not included in their training set. In the earliest days, developers either relied entirely on the model’s internal weights or added information to a static prompt. Next was Retrieval Augmented Generation, which is essentially another method of finding relevant information from external sources and adding it to the context window for the LLM to use. Tool calling came next, allowing LLMs to access external tools for both inputs and outputs. However, the issue here was that there was no standard for how various tools interacted with models and with each other. The current best practice for allowing AI models to interact with external data and tools is MCP, a standard created by Anthropic. MCP servers expose functions that the LLM can access to accomplish tasks in a standardized way—this is what Cora uses for their platform. InfluxDB has also created an MCP server to facilitate easy interaction with your InfluxDB instance using AI models.

Cora tech stack

The heart of Cora’s architecture is the gRPC server that acts as a coordinator between the MCP server, InfluxDB, and Firestore. InfluxDB is used to store all time series data, while Firestore is used to store basic user data, as well as any metadata relevant to specific time series metrics. Cora also uses the Firebase user ID to tag data stored with InfluxDB. InfluxDB is critical to the application because it can respond to queries fast enough to provide a real-time user experience, without requiring pre-computing statistics or other analytics. Below is an example of the data structure returned by Cora’s MCP server when an AI model requests a metric aggregation.

Next steps

There is a ton of exciting activity in the AI ecosystem, and Cora is a prime example. If you are interested in how developers are building applications that rely heavily on AI models, be sure to watch the full webinar to learn about more best practices and learn how to integrate InfluxDB with your application.

To try out Cora, sign up for the waitlist here.