Plant analytics on the data you already collect.
The edge devices add context to each signal and the private cloud keeps it running. This page is about using it: dashboards, reports, and models that read four databases through one semantic layer, where each metric is defined once. A shift report comes back in milliseconds, a three-year question scans 41.8 billion rows in seconds, and whoever is looking at the screen doesn't need to know which database answered.
The four data engines.
Plant data doesn't fit well in one database. Transactions, telemetry, batch files, and business context each suit a different engine, so each goes where it fits. An analytics layer on top joins them, holds the metric definitions, and serves every dashboard, report, and model from the same catalog. OEE is calculated one way, in every plant and every meeting.
The transactional record: orders, confirmations, quality results, e-signatures. Row-exact and constraint-checked.
4 ms lookups · audit-readyThe telemetry columnstore: every sensor value from every plant, compressed ~10:1 and replicated across nodes.
41.8B rows · secondsBatch records, lab exports, legacy CSV drops, and cold history, queryable in place without loading anything first.
versioned · query-in-placeItems, BOMs, standards, and costs on a read-only mirror, so production data can be costed safely.
read-only · business contextTransactional queries and analytical queries.
"Which operator signed off order 550123?" needs one exact row, exactly as committed. "What was the p95 cycle time on every filler over three years?" needs to scan billions of rows and answer before the meeting moves on. No single database is best at both, so we run one of each and send each query to the one built for it.
-- this morning's production, row by row, -- transactionally exact, mid-shift SELECT order_no, asset, good_count, reject_count, signed_by FROM production_confirmation WHERE shift_date = '2026-07-22';
-- three years, every plant, -- one columnstore sweep of 41.8B rows SELECT asset, quantile(0.95)(cycle_time_s) AS p95 FROM telemetry WHERE ts > now() - INTERVAL 3 YEAR GROUP BY asset;
Transactional reports
row-exact · audit-readyShift summaries, order confirmations, genealogy, and e-signature audit trails come out of MSSQL exactly as they were written. They're constraint-checked and can be queried mid-shift without blocking production writes, so an auditor's question is answered with a query.
Big-data sweeps
billions of rows · secondsClickHouse holds every telemetry point from every plant in a compressed, replicated columnstore. Year-over-year OEE, seasonal drift, and golden-batch comparisons across sites are aggregate queries over billions of rows, and they return in seconds while ingest keeps running at full rate.
Joins across engines
orders ⋈ telemetryThe useful questions usually need both, like reject counts from SQL next to the temperature trace from the columnstore, for the same order, on one chart. The analytics layer does the join and pushes each part of the query down to the engine that runs it fastest.
Live and history, one chart
stream + history · no gapDashboards read the Kafka tail for the last few seconds and the columnstore for everything before that. One line chart scrolls from three years ago to four seconds ago, with no visible break where one source hands off to the other.
The analytics we build first.
Most plant managers are asking the same short list of questions. We answer those first, from the same databases, and the numbers agree with each other because they come from one catalog.
The dashboards are what people see. The real value is that everyone works from the same numbers:
- One number per question. OEE, yield, and downtime are defined once in the metric catalog, so the Monday meeting argues about causes rather than calculations.
- Fast answers. Row lookups in milliseconds, three-year sweeps in seconds, live lines with sub-minute freshness, each from the engine built for it.
- Plants you can compare. Because the edge modeled every site the same way, a dashboard built for plant 1 works on plant 12 the day its data starts flowing.
- People answer their own questions. Engineers query with SQL, analysts with Power BI, operators with Grafana, all against the same governed catalog, behind SSO and role-based access.
- Room to grow into prediction. The same history that powers the reports trains the models, so predictive maintenance is a next step on infrastructure you already have.
Get in touch about your plant's numbers.
Tell us which number you can't get today: the OEE figure nobody trusts, the report that takes a day to build, the failure you'd like to see coming. We'll show you how to get from your data to that screen.
Start a conversation