It Works Until It Doesn’t: The Deceptive Success of Using a PLC as a Data Server

He wanted data. He got a production problem.

Users often like to use their PLC as a data server. This is a story about a user who tried it, learned why it was a problem for him and what he did to resolve it.

The “Quick Win” Trap

“Can we get some production data into my database?”

This is a common situation that many control engineers run into. An operations manager, a quality engineer or a maintenance manager asks a reasonable question:

“There are some tags in the PLC I’d like to see. Can we get them into a database so we can analyze them?”

Control engineers are accommodating people and they want to help. They look at the situation and see that their PLC has an assortment of communication interfaces, and it looks like a quick win: It should be easy to connect an SQL database to a PLC and get the data.

So, they do. Sometimes it’s a little more difficult than they expect, but they are result-oriented and they get it done.

The Data Integrity Gap

Problems don’t show up right away, but they arrive.

The PLCs were stable. Production was on schedule. Everything seems fine.

Data appears in the database. Dashboards get populated. The manager asking the original question is happy. Until reality arrives.

There are database issues. Some data points are missing. The timestamps (if there are any) don’t seem to make sense. There are inexplicable gaps in the database. The data consumers thought the data looked good enough to trust, but not good enough to rely on. The problem for these users was that the data wasn’t adequate for solid decision-making.

Some PLC issues appeared. The PLC scan time crept up after a minor logic change. Not a major concern. There was scan time to spare.

Nothing failed catastrophically. That was the problem.

Cybersecurity Red Flags

The bigger problem: That connection violated plant cybersecurity rules. It’s NEVER a good idea to hook programmable controllers controlling vital machine processes to a computer that can be hacked. IT started asking uncomfortable cybersecurity questions.

The Three Absolutes of Plant Manufacturing

This wasn’t a database problem. It wasn’t a PLC problem. The architecture was the problem. Connecting a PLC directly to equipment outside the production zone is a huge no-no in 2026.

The real problem with this type of architecture is that direct PLC-to-database connections do not fail loudly. They fail subtly, over time, under load and during change.

That is the most dangerous failure mode in manufacturing.

This architecture violates one of the three absolutes for plant manufacturing in 2026:

1. The plant cannot risk control performance. Plant personnel must be very careful about what is connected directly to a PLC. PLC logic can’t be overloaded with data plumbing.
2. Data is vital to manufacturing operations, and it must be trusted 100% without exception. The data must be defensible in audits and reviews
3. The system must survive outages

A Better Architecture for Moving PLC Data to a Database

The best architecture for moving PLC data to a database is a local historian in the production cell. Don’t try to make the PLC behave like a data server. Keep the PLC focused on scanning I/O and solving logic. Let a Historian do the job it is meant to do, collecting data and pushing it to external databases and applications.

The Advantages of a Local Historian

1. The data finally had a trustworthy timeline
   Every value was timestamped when it happened, not when it arrived. Sequence problems disappeared. Root cause analysis became possible again.
2. Data loss stopped being a mystery
   When the network or database went down, the historian buffered data locally. When connectivity returned, the data flowed automatically. There were no scripts to write. No manual backfills to install and no guessing.
3. PLC performance stabilized
   Database drivers were removed from the control logic. The scan time stopped fluctuating.
   Future logic changes no longer threatened the data path.
4. The context (units, tag names, location, etc.) stopped getting lost
   The numbers finally meant something.
5. Cybersecurity conversations got easier
   The historian became a clean boundary between zones. IT was happy with the controlled conduit between the process zone and the IT databases. The PLC was now isolated.

Why This Architecture Works in the Real World

A local, store-and-forward historian solves problems users do not want to own:

1. Time integrity
2. Buffering and store-and-forward
3. Scheduling and change-based capture
4. Normalization and context
5. Diagnostics when things go wrong

These are not “nice to have” features. They are the difference between data that informs decisions and data that misleads them.

What Do You Lose by Not Using a Historian?

Trying to save money or time by skipping a historian usually costs more in debugging time, rework, security reviews and operational risk.

The engineer did not add the RTA Historian to get more data. He added it to get more data more reliably. That distinction is everything.

Reliability over Accessibility

If you recognize yourself in this story, your intention is right—you want accessible data. The real solution is using the right tool: let historians bridge PLCs and databases, keeping control safe and data trustworthy.

Once that boundary is in place, everything else gets easier.

Have questions or need more information?
Checkout the RTConnect A-B PLC Historian from Real Time Automation – it’s designed exactly for this situation. Or you can visit the RTA Learning Center, contact an RTA Enginerd application engineer at 262-436-9299 or solutions@rtautomation.com for more information.