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

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.

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

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.

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.

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.