Skip to content
Industrial · IoT · Any Sensor or Streaming Data

You Have the Sensor Data.
Cross-plant queries, complex analytics, and high cardinality are where your stack stalls.

CrateDB connects to your existing OT stack and runs OEE, predictive maintenance, and cross-plant queries on live sensor data. Standard SQL. No historian replacement required.

The data is there. The analytics are not. Your historians and PLCs ingest at scale without issue. The problem shows up when you need answers beyond basic OT reporting.

Where traditional systems fall short

Traditional time-series databases were designed for one thing: ingest a stream of metrics, query it back by time. Add device categories, plant locations, shift codes, and production run IDs and the model breaks. Each new dimension multiplies the number of storage structures the database has to manage. Queries slow down structurally, not because the data grew, but because the context did.

The result is two systems: one that ingests, one that answers questions. Every operational decision waits for data to move between them.

Complex multi-dimensional queries run slowly

OEE calculations that join sensor readings, ERP downtime codes, and shift data across systems take minutes instead of milliseconds. How OEE queries run in milliseconds, not minutes →

Multi-site consolidation requires exports

Cross-plant analysis means scheduling data exports from each historian before any cross-site query can run, adding hours of latency before anyone can act. Cross-plant visibility in one SQL query →

High-volume ingest and real-time queries compete

Databases optimized for ingestion degrade when analytical queries hit the same data as it arrives. IoT analytics architecture: ingest and query on the same data →

No real-time analytics on freshly ingested data

Queries run on snapshots. By the time a report reaches your operations team, the moment to act has passed. From nightly exports to real-time dashboards →

High-cardinality ingest degrades query performance

The more sensor types, device categories, and plant locations you add, the slower queries get as a structural consequence of the data model. Why high-cardinality industrial data breaks InfluxDB →

Schema changes disrupt live pipelines

Adding a new sensor type requires a migration that means downtime or a carefully coordinated dual-write period.
industrial analytics with cratedb

Connect to your OT stack. Query the moment data arrives.

Connect without replacing

CrateDB connects to your existing industrial infrastructure without replacing a single OT system. Telegraf (with 300+ input plugins) covers OPC-UA, MQTT, SCADA, Kafka, industrial historian outputs, REST APIs, and virtually any sensor protocol or data source, without custom connectors. Your PLCs, historians, and SCADA infrastructure stay in place. CrateDB adds the analytics layer on top.

Index everything on ingestion

CrateDB indexes every field automatically on ingestion, enabling performant ad hoc queries on live data without pre-aggregation or index planning. No manual index management, no batch loading step, no DBA required.

cr-quote-image

Standard SQL, existing tools

Write standard SQL with joins, CTEs, window functions, and aggregations. Your existing BI tools and dashboards connect via the PostgreSQL wire protocol. No custom drivers, no new query language for your team to learn.

Dynamic columns

Add a new sensor type: CrateDB handles it with dynamic columns. No schema migration, no downtime, no pipeline rewrite.
cr-quote-image

Two queries manufacturing teams run every shift.

Computing OEE from live shift records and correlating sensor anomalies with ERP downtime codes are different operations, but they share the same blocker: both normally require an export step before the query can run. In CrateDB, both execute in standard SQL directly against live operational data. 

        

/* This query returns the average sensor value per asset and sensor type, correlated with the ERP downtime reason, across the last hour: */
SELECT
  s.asset_id,
  s.sensor_type,
  AVG(s.value) AS avg_value,
  d.downtime_reason
FROM sensor_data s
JOIN erp_downtime d ON s.asset_id = d.asset_id
  AND s.timestamp BETWEEN d.start_time AND d.end_time
WHERE s.timestamp > NOW() - INTERVAL '1 hour'
GROUP BY s.asset_id, s.sensor_type, d.downtime_reason;
        

+-----------+-------------+--------------------+--------------------------------+
| asset_id  | sensor_type |          avg_value | downtime_reason                |
+-----------+-------------+--------------------+--------------------------------+
| asset-001 | vibration   |              0.465 | overheating threshold exceeded |
| asset-002 | temperature |               80.3 | scheduled lubrication          |
| asset-001 | temperature |  87.23333333333333 | overheating threshold exceeded |
+-----------+-------------+--------------------+--------------------------------+

        

-- Current shift OEE by production line
-- Availability × Performance × Quality, ranked lowest-first
SELECT
    plant_id,
    line_id,
    ROUND(
        (SUM(runtime_seconds) / NULLIF(SUM(planned_seconds), 0.0))
        * (SUM(actual_output)  / NULLIF(SUM(ideal_output),   0.0))
        * (SUM(good_units)     / NULLIF(SUM(actual_output),  0.0))
        * 100.0,
        1
    ) AS oee_pct,
    ROUND(SUM(runtime_seconds) / NULLIF(SUM(planned_seconds), 0.0) * 100.0, 1) AS availability_pct,
    ROUND(SUM(actual_output)   / NULLIF(SUM(ideal_output),   0.0) * 100.0, 1) AS performance_pct,
    ROUND(SUM(good_units)      / NULLIF(SUM(actual_output),  0.0) * 100.0, 1) AS quality_pct
FROM shift_production
WHERE ts >= DATE_TRUNC('day', NOW())
GROUP BY plant_id, line_id
ORDER BY oee_pct ASC;
        

+----------+---------+---------+------------------+-----------------+-------------+
| plant_id | line_id | oee_pct | availability_pct | performance_pct | quality_pct |
+----------+---------+---------+------------------+-----------------+-------------+
| plant_a  | line3   |    61.4 |             79.2 |              87 |        89.1 |
| plant_a  | line2   |    77.9 |             90.3 |              93 |        92.7 |
| plant_a  | line1   |    89.8 |             96.5 |            96.5 |        96.4 |
+----------+---------+---------+------------------+-----------------+-------------+

Additional resources

Run where your data lives.

CrateDB runs on-premises, at the factory edge, or in the cloud. For deployments where data sovereignty or network constraints apply, CrateDB Enterprise deploys in your own infrastructure (on-premises or in a private cloud environment). The same SQL, the same query behavior, across all environments.

Data from on-premises factory clusters syncs to cloud clusters via Logical Replication (CrateDB's built-in feature for replicating data between instances). Operational queries run locally against live data. Aggregated or enriched data flows to the cloud for cross-site analytics and AI workloads.

Want to explore CrateDB?

Examples of industrial workloads in production

ABB Ability™ Genix optimizes operations and increases asset availability in industrial use cases by analyzing vast amounts of data in real time. With a data ingestion rate of an 1 million values per second and event retrieval ranging from 30,000 to 120,000 events per second, ABB optimizes industrial efficiency and productivity.

"Working with CrateDB brings positive outcomes. The ingestion and throughput have very good performance, with 1 million values/sec, the horizontal scalability where we can add as many nodes as we need and the automatic query distribution across the whole cluster"

Marko Sommarberg
Lead, Digital Strategy and Business Development
ABB

EV-Charging-Station-cropped
TGW Logistics Group is one of the leading international suppliers of material handling solutions. As systems integrator, TGW plans, produces and implements complex logistics centres, from mechatronic products and robots to control systems and software. 

Using CrateDB, TGW accelerates data aggregation and access from warehouse systems worldwide, resulting in increased database performance. The system can handle over 900,000 sensors per distribution center.

"CrateDB is a highly scalable database for time series and event data with a very fast query engine using standard SQL".

Alexander Mann
Owner Connected Warehouse Architecture
TGW Logistics Group

TGW-warehouse
SPGo! is part of PETROMIN, which has more than 23 years of experience in the mining and oil industries. They build applications for monitoring all material conveyor belt idlers every minute 24 hours a day through online sensors. They use CrateDB as a central database to capture and query data from 30,000 sensors per mine, representing 760 million records a day.

"With CrateDB, we can continue designing products that add value to our customers. We will continue to rely on CrateDB when we need a database that offers great scalability, reliability and speed."

 

Nixon Monge Calle
Head of IT Development and Projects
SPGo! Business Intelligence

SPGo

Resources

Webinar
From Sensors to Dashboards: Building Real-Time Analytics Pipelines That Actually Work
From Sensors to Dashboards: Building Real-Time Analytics Pipelines That Actually Work

The promise of real-time data is everywhere, but for most engineering teams, the reality is a nightmare of stale data, system bottlenecks, and lagging dashboards that are useless for operational decisions. If your team is spending more time tuning infrastructure and reprocessing data than delivering new value, you are not alone. Watch this recording to learn the three principles for building real-time analytics that work.

Talk
How-ABB-Ability-Genix-applies-AI-and-analytics-to-unlock-the-value-of-industrial-data-with-CrateDB-02
ABB: AI and Analytics applied to Industrial Data

In this talk, Marko Sommarberg, Lead Digital Strategy and Business Development at ABB, explaine how ABB Ability™ Genix applies AI and analytics to unlock the value of industrial data using CrateDB.

Talk
Not-All-Time-Series-Are-Equal_Challenges-of-Storing-and-Analyzing-Industrial-Data
TGW Logistics: Not All Time-Series are Equal

This talk at the IoT Tech Expo 2023 explores the complexities of industrial big data, characterized by its high variety, unstructured features, and different data frequencies. It also analyzes how these attributes influence data storage, retention, and integration when dealing with an IoT database.

Tutorial
HiveMQ
Setup HiveMQ using CrateDB as consumer

This blog post gives you an overview of how to set up HiveMQ using CrateDB as a consumer.

Video
Unstoppable Insights: Resilient Data Streaming with CrateDB
Unstoppable Insights: Resilient Data Streaming with CrateDB

Explore the resilience of CrateDB for real-time data streaming in a demonstration of node failure scenarios. This video illustrates the capabilities of a distributed CrateDB cluster to maintain operational continuity during both a graceful shutdown and an abrupt unavailability of a database node within a 3-node configuration. Witness firsthand how continuous data ingestion is sustained, underscoring CrateDB's inherent high availability.

Webinar
IIoT World Manufacturing & Supply Chain Day: From Data Overload to Actionable Insights: Mastering Data Management in Manufacturing
From Data Overload to Actionable Insights: Mastering Data Management in Manufacturing

This session delves into the challenges of managing vast amounts of data and demonstrates how real-time analytics can transform raw data into valuable insights. Learn how modern data management solutions enable manufacturers to optimize production, improve operational efficiency, and drive innovation. From harnessing data streams in real-time to leveraging AI-powered analytics, this session will equip you with the tools to master data management and make faster, data-driven decisions.

Want to explore CrateDB?

FAQ

No. CrateDB adds an analytics layer above your existing OT infrastructure. Historians, PLCs, and SCADA systems stay in place. Telegraf reads from them via OPC-UA, MQTT, historian outputs, or direct API connectors and writes to CrateDB. The historian continues handling OT-layer data collection. CrateDB handles the analytical queries historians were never designed for.

Yes. CrateDB uses Telegraf for ingestion. Telegraf includes native inputs.opcua, inputs.opcua_listener, and inputs.mqtt_consumer plugins. Data from PLCs, SCADA systems, and MQTT brokers flows into CrateDB through a single Telegraf configuration file. No middleware, no custom connector development.

Performance does not degrade as dimensions grow. In traditional time-series databases, each new combination of tags (sensor type, plant, asset) becomes a separate storage series and query time grows structurally as cardinality increases. CrateDB stores additional dimensions as object columns, so adding a new sensor type or plant location does not create a new storage structure. ABB Ability Genix ingests 1 million values per second and retrieves 30,000 to 120,000 events per second on CrateDB.

Yes. CrateDB Enterprise deploys in your own private infrastructure, on-premises or in a private cloud. Production data does not leave your facility. For deployments that also require cross-site analytics, Logical Replication syncs selected data to a central CrateDB Cloud cluster. Operational queries run locally against live data. Cross-plant queries run against the cloud cluster. The SQL is identical in both environments.

No. CrateDB speaks standard SQL over the PostgreSQL wire protocol. Existing Grafana dashboards, Tableau reports, Power BI connections, and ORMs connect without modification. OEE calculations, cross-plant aggregations, and sensor-to-ERP joins are all standard SQL. No Flux, no InfluxQL, no proprietary syntax to learn or maintain.