InfluxDB

What is InfluxDB?

InfluxDB is an open source Time Series Database from the US company InfluxData, built to write large volumes of time-stamped measurements, such as sensor data, machine states and network statistics, at high speed, store them compactly and analyse them per time interval. In OT and industrial automation environments, InfluxDB often serves as the storage layer behind Grafana dashboards, as a lightweight complement to a traditional Historian and as a data source for Predictive Maintenance. The database has existed since 2013 and is now in its third generation, which runs on an entirely new storage engine.

🧠 How did InfluxDB evolve and which versions exist?

InfluxDB was first released on 24 September 2013 by Errplane, a company that renamed itself InfluxData in late 2015. Versions 1 and 2 are written in Go; version 3 was rebuilt from scratch in Rust. In 2016 InfluxData decided to offer clustering only as a commercial product, so the open source editions of versions 1 and 2 remained single-node.

InfluxDB 3 Core is released under the MIT and Apache 2.0 licences and targets a single node and recent data. InfluxDB 3 Enterprise adds, among other things, high availability with automatic failover, read replicas and efficient queries over long historical periods. InfluxData also offers managed cloud editions. Version 3 accepts the write APIs of versions 1 and 2, so existing collectors usually keep working.

⚙️ How does InfluxDB store measurement data?

Data arrives in a text format called line protocol. Each line describes one data point:

temperature,line=L2,sensor=oven01 value=185.4 1715678000000000000

Tags in InfluxDB differ from a PLC tag: a PLC tag is a single data point in the controller, whereas an InfluxDB tag is a label. Every unique combination of measurement and tag values forms a series, and the number of series is called cardinality. In versions 1 and 2, high cardinality is the best-known cause of memory problems and slow queries, for example when a batch number, order number or timestamp is stored as a tag. Version 3 handles this far better thanks to its columnar storage, but a well-designed data model remains the foundation of scalability.

🔄 How does OT data get into InfluxDB?

InfluxDB does not speak fieldbus protocols itself. Data arrives through collectors, gateways or middleware running at the edge. The standard collector is Telegraf, InfluxData’s own open source agent, written in Go and released under the MIT licence, with more than 300 plugins for input, processing and output.

Common pipelines are PLC → OPC UA server → Telegraf → InfluxDB, sensors → MQTT broker → Telegraf → InfluxDB, and existing historian → export → InfluxDB. Alternatives to Telegraf include Node-RED and streaming platforms such as Apache Kafka. The physical network underneath is often Industrial Ethernet.

🏭 What is InfluxDB used for in industry?

• Process monitoring - temperatures, pressures, flows, tank levels and energy consumption as historical trends.
• Machine monitoring and condition monitoring - vibration, rotational speed, motor currents and cycle times as the basis for predictive maintenance.
• Production performance - downtime and good/reject counts for OEE.
• Energy management - power peaks, power quality and gas and water consumption per line or building.
• OT network monitoring - latency, jitter, bandwidth, switch load and packet loss via SNMP.
• IIoT and digital twins - central storage of data from Industrial Internet of Things devices to feed Industrial AI models.

The data comes from PLCs, sensors, SCADA systems and edge devices. Visualisation usually happens in Grafana, which supports InfluxDB as a standard data source.

📉 Which query languages does InfluxDB support?

• InfluxQL - a SQL-like language with time functions such as GROUP BY time(1m). It is available in all three generations, making it the most future-proof choice for existing dashboards.
• Flux - a functional scripting language introduced with InfluxDB 2 for pipelines, joins and tasks. Flux is now in maintenance mode: it only receives security patches and critical fixes, and InfluxDB 3 does not support Flux.
• SQL - in InfluxDB 3 via the Apache DataFusion engine, which means regular BI and data analysis tools can also work with InfluxDB.

If you still rely on Flux tasks, you will need to rewrite them in SQL, InfluxQL or Python plugins when migrating to version 3.

📈 Can InfluxDB replace a historian?

InfluxDB is often deployed alongside or instead of a traditional Historian such as OSIsoft PI (now AVEVA PI). The choice depends on your requirements.

In pharmaceuticals, food production and critical infrastructure, traditional historians often remain dominant because of validation, built-in connectors and vendor support. InfluxDB is strong in monitoring, IT-style integration through APIs and projects where a quick, low-cost start matters.

🧩 How do you set up InfluxDB for OT data in practice?

A proven approach for a production site:

1. Define the data model - choose measurements per type of measurement and tags for fixed attributes such as site, line and asset; keep variable values in fields.
2. Decide on sampling rates - not every signal needs one-second resolution; process data every 1 to 10 seconds is often enough, while vibration analysis needs higher rates.
3. Tune Telegraf - by default Telegraf collects every 10 seconds, writes in batches of 1,000 metrics and buffers up to 10,000 unwritten metrics per output; when the buffer is full, the oldest metrics are overwritten. Increase the buffer at the edge if the link to the data centre may drop.
4. Batching and compression - InfluxData recommends batches of about 5,000 lines of line protocol, sorted tags, the coarsest usable timestamp precision and gzip compression.
5. Retention and downsampling - keep raw data briefly and aggregates for a long time, see the table below.
6. Monitor the database itself - watch disk usage, memory and query times, and maintain a backup plan.

In version 1 you implement downsampling with continuous queries, in version 2 with tasks and in version 3 with Python plugins in the processing engine. This keeps storage growth under control as part of data lifecycle management.

🔐 How do you secure InfluxDB in an OT environment?

InfluxDB often holds sensitive process information, which makes it an attractive target. Key points for InfluxDB cybersecurity:

• Enable authentication - in InfluxDB 1.x authentication is disabled by default and every user has all privileges. Versions 2 and 3 use tokens by default.
• Patch - the vulnerability CVE-2019-20933 allowed attackers to bypass JWT authentication in InfluxDB before 1.7.6 because an empty shared secret was accepted; public exploits exist. Regular patch management prevents this kind of risk.
• Encryption and permissions - use TLS, tokens with minimal rights following least privilege and RBAC, and MFA on management environments and cloud consoles.
• Network placement - do not expose InfluxDB to the internet or place it in the control layer; put it in a separate zone or the IDMZ according to the Purdue Model and network segmentation with a firewall. Let edge collectors push data upwards so no inbound connections into the OT network are needed. A data diode can enforce that direction.
• Hardening - close unused ports (8086, 8181), disable unnecessary endpoints and run containers such as Docker with minimal privileges.

These mitigating measures align with IEC 62443, the zones and conduits model, and the duty of care under NIS2 and the Dutch Cybersecurity Act. Preferably, do not connect InfluxDB directly to field equipment.

☁️ Where does InfluxDB run: edge, on-premise or cloud?

• On-Premise - common in manufacturing and critical infrastructure, including isolated OT networks without internet access.
• Edge - a small instance near the machine or line buffers data during connection loss, provides low latency for local dashboards and often runs in containers on an industrial PC, close to production assets.
• Cloud - suited to central analysis across multiple sites and to scaling without in-house administration.

For redundancy, the open source editions mainly offer backups, edge buffering and dual writes; true high availability with automatic failover is part of InfluxDB 3 Enterprise and the commercial cluster products. At larger scale InfluxDB also runs on Kubernetes.

🏗️ What role does InfluxDB play in IT/OT convergence?

Within OT convergence, InfluxDB often forms the bridge between OT assets and IT analytics platforms. In the ISA-95 model the database sits at level 3 or higher: close enough to production for current data, yet separated from control. This data layer supports Industry 4.0 initiatives, unified monitoring of IT and OT systems, energy analytics and data-driven maintenance. At the same time, the architecture demands attention to data governance, data quality, security and data ownership between IT and OT.

❓ Frequently asked questions

Is InfluxDB free?

InfluxDB 3 Core is free and open source under the MIT and Apache 2.0 licences, as are the open source editions of InfluxDB 1 and 2. Features such as high availability, read replicas and efficient historical queries are part of the commercial InfluxDB 3 Enterprise. InfluxData also offers paid cloud editions.

What is the difference between InfluxDB and Grafana?

InfluxDB is a database that stores and queries time series, whereas Grafana is a visualisation tool that builds dashboards on top of data sources. In OT environments they are often used together: InfluxDB holds the measurement data and Grafana displays trends and alerts. Grafana can also show data sources other than InfluxDB.

Can InfluxDB communicate directly with a PLC?

InfluxDB does not speak industrial protocols such as OPC UA, Modbus or S7 itself. A collector such as Telegraf or Node-RED reads the PLC or an OPC UA server and writes the values to InfluxDB. This is also more secure, because the database then needs no connection to the control layer.

Is Flux still supported in InfluxDB?

Flux still works in InfluxDB 1.x and 2.x, but it is in maintenance mode and only receives security patches and critical fixes. InfluxDB 3 does not support Flux and uses SQL and InfluxQL instead. If you plan to migrate to InfluxDB 3, you need to rewrite your Flux queries and tasks.

What is cardinality in InfluxDB?

Cardinality in InfluxDB is the number of unique series, meaning the number of unique combinations of measurement and tag values. Excessive cardinality, for example from storing order numbers as tags, can cause memory problems and slow queries in InfluxDB 1 and 2. Fixed attributes therefore belong in tags and variable values in fields.

Is InfluxDB suitable for critical infrastructure?

InfluxDB is suitable for monitoring and analysis in critical infrastructure, provided it runs in a separate network zone with authentication, TLS and up-to-date patching. For validated processes or heavy connector requirements, organisations often still choose a traditional historian. Availability requirements may also call for the commercial Enterprise edition.

📌 In summary

InfluxDB is an open source time series database that quickly stores time-stamped OT and IT measurements and analyses them per time interval, usually fed by Telegraf and visualised in Grafana. With three generations (1.x, 2.x and the Rust-based InfluxDB 3 since April 2025), the InfluxQL and SQL query languages, retention and downsampling, and security through authentication, TLS and network segmentation, InfluxDB provides a flexible data layer for monitoring, energy management and predictive maintenance within IT/OT convergence.