# For constant plant-floor process streams, a data historian is often a better fit than SQL Server or Oracle

By MarketScale Newsroom · Published 2026-09-30 · Industrial IoT on MarketScale
Canonical: https://www.marketscale.com/industries/industrial-iot/plant-floor-process-data-belongs-in-a-data-historian-not-sql-server-or-oracle-1218050

> Bill Schmidt explains why high-speed plant-floor process data belongs in a data historian, and where SQL Server and Oracle still earn their keep.

## Key points

- Precedence Research values the industrial IoT market at USD 602.87 billion in 2026, growing 16.8% a year to 2035, so plant data streams keep getting larger.
- In Schmidt’s example, historians can store a timestamped point when a value changes (skipping repeats), while logging every repeated reading in a relational table can increase storage and slow time-window reports.
- Historians such as AVEVA PI handle capture; CrateDB and Tiger Data say cross-plant SQL analytics is a separate layer added beside them, and generic relational tables degrade as they grow.

Bill Schmidt starts with a line he says he hears everywhere: I want more data, I need data, I cannot make a business decision without data. Then he asks the question that follows it. Where does all of that data go?

Speaking in a recorded segment titled Data Historian, Schmidt, principal solution consultant in the Industrial Solutions Group at Renson House, says most business systems answer by reflex and write it to Microsoft SQL Server, Oracle or something like them. For the plant manager who wants a temperature trend on a line, and the CIO who signs off on the server that holds it, that reflex decides how fast the report comes back and how much disk it eats.

The volume behind the question keeps rising. In a press release updated September 15, 2026, Precedence Research valued the global industrial IoT market at USD 602.87 billion in 2026 and projected USD 2,430.21 billion by 2035, a 16.8% compound annual growth rate, with manufacturing the largest end use in 2025. Mordor Intelligence's 2026 report estimates the manufacturing slice alone at USD 0.61 trillion in 2026, up from USD 0.49 trillion in 2025, and puts predictive maintenance at 25.40% of that spending in 2025.

Every one of those projects lands more sensors on the floor, and every sensor writes to something. Schmidt's argument is that the something should be chosen for the shape of the data.

## A query for employees named Smith is a different job from a temperature feed

Schmidt defines a transactional database by what it does well. Store every employee and their history, then ask for everyone worldwide with the last name Smith, and the answer comes straight back. That is a transaction, in his telling, and SQL Server and Oracle were built for it.

> That is a constant stream of process data. We're constantly getting, here's your temperature, here's your temperature, here's your temperature. It's coming at us fast and constant. That is not what a transactional database was designed for. — Bill Schmidt, Principal Solution Consultant, Industrial Solutions Group, Renson House

Mipac drew the same line in an October 2023 guide on its own site. Historians are tuned for time-stamped points and retrieve them quickly through specialized storage and indexing, Mipac wrote, while SQL databases are flexible relational stores that are generally slower on time series and tend to keep data in raw form.

For a procurement director, the distinction is the difference between a tool that answers a question and a tool that keeps up with a stream. SQL Server and Oracle were built to answer a question; a plant sensor never stops talking. A temperature tag arrives as the same value, again and again, until it moves.

## The historian records the change and the clock, and skips the repeats

> Things like if I'm recording a temperature, let's say, and it's been constant at a 100 degrees Fahrenheit for the last hour, why do I need to store a data point every ten seconds, when really I only need to know when it changes from its last value. And I need to know the timestamp associated with that, so I can have context around that data. — Bill Schmidt, Principal Solution Consultant, Industrial Solutions Group, Renson House

That is the storage argument in one example. A historian keeps the timestamp and the new value when a reading moves, and skips the rest. Schmidt calls that intelligence, and he says the generic database has none of it built in.

CrateDB, a database vendor, describes the same model in an undated data guide on its own site. Each measurement in a historian is stored as four fields, tag name, timestamp, value and quality code, a design CrateDB says was built for plants where thousands of points stream every second and the write has to land every time.

> A transactional database doesn't have that intelligence baked into it. If I'm going on the reporting side and I wanna get that data out, that's where a data historian can really shine. It's fast on the input side, and it's fast on the output side. — Bill Schmidt, Principal Solution Consultant, Industrial Solutions Group, Renson House

The reporting side is where the reader feels it. A supervisor pulling an hour of temperature history from a table that logged every repeat waits on a scan of rows that carry no new information. Pulling the same hour from a store that logged only the changes returns faster, and Schmidt's word for those reports is snappy.

Mipac's 2023 guide adds the cost angle. Historians commonly compress large data sets, Mipac wrote, while SQL databases holding raw readings can need more storage for the same history. That is the figure the CFO sees on the storage invoice, even when nobody on the floor ever asks for the old readings.

## Where the historian argument runs into its own ceiling

The comparison is not clean all the way down, and two of the vendors who publish on it sell the alternatives. In a May 27, 2026 post on its own site, CrateDB's Stephane Castellani argued that framing the decision as historian versus time series database is how teams end up solving the wrong problem. Historians such as AVEVA PI System, Honeywell Uniformance, AVEVA Historian and Siemens SIMATIC Historian dominate operational data capture, he wrote, speak OPC-UA and Modbus natively and carry certified data integrity that auditors accept.

What they are not built for, in Castellani's account, is analysis that spans assets or plants: OEE across several lines, cross-plant queries, or joins against ERP and MES records. Tiger Data, which sells a time series database, made a parallel point in an August 2026 post on its own site. Many manufacturers already run an AVEVA PI System or a similar historian that absorbs the incoming volume, Tiger Data wrote, yet teams increasingly want dashboards and machine learning on that data in standard SQL instead of a proprietary query interface that only a few specialists know.

CrateDB's data guide puts a scale figure on the ceiling. TGW Logistics runs 900,000 sensors per distribution center and ABB ingests 1 million values per second, CrateDB writes on its own site, and at those volumes proprietary storage formats built for another era become bottlenecks.

None of this contradicts Schmidt. Tiger Data's same post says manufacturers who dump plant data into a generic relational database watch performance degrade as tables grow past what standard indexing was designed to handle, which is the failure Schmidt describes. His claim is narrower than a full architecture. The capture layer for a high-speed stream should be a historian. He does not say the historian replaces the transactional database, and he does not say it is the last stop for the data.

> Not that people can't use a transactional database for these types of things. It's just the efficiency of it. It's the right tool for the right job. — Bill Schmidt, Principal Solution Consultant, Industrial Solutions Group, Renson House

The operator's reading: keep SQL Server or Oracle for recipes, invoices and records, put the process stream in a historian, and treat cross-plant analytics as a separate decision, the one CrateDB says most teams reach when the historian's analytics feel thin.

## Three questions before the next sensor project writes its first row

Schmidt reduces the decision to a test he states in the segment: what type of data is it, how is it coming in, and how do you need to report on it. A historian, in his words, knows what process data looks like. A transactional database is more generic.

- Type: is it a record that changes when someone edits it, such as a recipe, an invoice or an employee file, or a value a sensor emits continuously?
- Arrival: does it show up as discrete transactions, or as a constant high-speed stream from the floor?
- Reporting: is the report a lookup across records, or a time window on a tag that has to load fast for someone standing at a line?

Deployment shapes the answer too. Mordor Intelligence's 2026 report found cloud deployments held 56.30% of manufacturing IoT spending in 2025 and projects hybrid edge-cloud architectures to grow at a 29.2% CAGR to 2031. CrateDB's data guide notes that the on-site versus cloud choice for a historian changes data latency and where OT protocol translation happens, a decision the controls engineer and the IT architect have to make together.

The signal to watch is the one Tiger Data and CrateDB both describe: the moment a team starts asking for SQL against the historian's data. CrateDB's May 2026 advice is to keep the historian for capture and put analytics beside it rather than pull the historian out. Schmidt's test comes first. If the data is a constant stream from the floor, the first place it lands should already know what a repeated reading is worth, and Schmidt says a temperature that has not changed in an hour is a reading nobody needs to keep.

## Sources

- [What Is a Data Historian?](https://cratedb.com/data/data-historians) (CrateDB)
- [Data Historian vs. Time Series Database: Which Belongs in Your Industrial Stack](https://cratedb.com/blog/data-historians-vs-time-series-databases) (CrateDB)
- [The crucial role of data historians in industrial process operations](https://www.mipac.com.au/insights/crucial-role-data-historians/) (Mipac)
- [IIoT in Manufacturing: The Data Challenges Behind Industry 4.0](https://www.tigerdata.com/blog/top-5-iot-manufacturing-industry-trends-and-their-data-challenges) (Tiger Data)
- [Industrial IoT Market Companies, Size & Trends 2026-2035](https://www.precedenceresearch.com/industrial-iot-market) (Precedence Research)

Tags: CED, Renson House, data historian, industrial IoT, manufacturing, plant operations

---
Source: MarketScale, https://www.marketscale.com/industries/industrial-iot/plant-floor-process-data-belongs-in-a-data-historian-not-sql-server-or-oracle-1218050. Published for AI indexing and citation; cite the canonical URL. Site guide for agents: https://www.marketscale.com/llms.txt