Every line, every shift, one pane of glass.
The edge devices contextualize the signal and the private cloud keeps it alive. This layer is the payoff: dashboards, reports, and models that read four connected engines through one semantic layer, with one definition of every metric. A shift report lands in milliseconds, a three-year question sweeps 41.8 billion rows in seconds, and the person watching the screen never learns which engine did the work.
Four engines feed that screen.
Manufacturing data refuses to live in one database, and it shouldn't: transactions, telemetry, batch files, and business context each want a different engine. So each gets the right one, and an analytics layer on top joins them, holds the metric definitions, and serves every dashboard, report, and model from the same catalog. OEE means one thing here, in every plant, in 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 plant math can become money math safely.
read-only · business contextThe report and the sweep run on different physics.
"Which operator signed off order 550123?" wants one exact row, transactionally guaranteed. "What was the p95 cycle time on every filler across three years?" wants to scan billions of rows and come back before the meeting moves on. One engine cannot be best at both, so the platform runs one of each and routes every question to the engine 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: row-exact, constraint-checked, and queryable mid-shift without blocking production writes. When an auditor asks, the answer is a query away.
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, golden-batch comparisons across sites: aggregate queries over billions of rows return in seconds, while ingest continues at full rate.
Joins across engines
orders ⋈ telemetryThe interesting questions span both: reject counts from SQL joined to the temperature trace from the columnstore, for the same order, on one chart. The analytics layer does the stitching, pushing each part of the query down to the engine that is fastest at it.
Live and history, one chart
stream + history · seamlessDashboards read the Kafka tail for the last few seconds and the columnstore for everything before that, seamlessly. A line chart scrolls from three years ago to four seconds ago, and the operator watching it never learns where one engine ends and the other begins.
What manufacturing actually asks for.
The stack exists to answer a short list of questions every plant manager already has. These are the ones we build first, from the same connected engines, with numbers that agree with each other because they share a catalog.
The dashboards are the visible part. What you're actually buying is agreement:
- 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.
- Answers at the speed of the question. Row lookups in milliseconds, three-year sweeps in seconds, live lines with sub-minute freshness, each from the engine built for it.
- Cross-plant comparability for free. 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.
- Self-serve for the people who ask. Engineers query with SQL, analysts with Power BI, operators with Grafana, all against the same governed catalog, behind SSO and role-based access.
- A path from hindsight to foresight. The same history that powers the reports trains the models, so predictive maintenance is a next step on infrastructure you already have.
Which panel would you watch first?
Tell us the number you can't get today: the OEE you don't trust, the report that takes a day to build, the failure you'd love to see coming. We'll show you the path from your data to that screen.
Start a conversation