Direct connections between PLCs and databases are a fundamentally flawed architecture for production environments. They introduce cybersecurity risks, lack timestamping and data context, offer brittle error handling and scale poorly. In the limited use cases where direct connections are justifiable, strict firewall rules and zone separation are essential.

This article examines ten core reasons why direct PLC-to-database connections fail in practice, identifies the narrow scenarios where they may be acceptable and recommends proven alternative architectures that optimize security, reliability and maintainability.

Why Store PLC Data in a Database?

In modern manufacturing, plant floor data must feed upstream analytics systems to optimize production processes. The manufacturing database serves as the common denominator for archiving and preserving this data.

When PLC data is properly transferred to a database, it enables a wide range of plant floor applications:

• Energy Management — Leveraging plant floor data to optimize energy usage, a major expense for manufacturers
• Predictive Maintenance (PdM) — Monitoring cycle counts, valve response times and other inputs to forecast failures before they occur
• Traceability and Compliance — Saving operational data to demonstrate compliance with safety and quality standards in regulated industries
• Quality Control — Detecting variations and defects through continuous operational data analysis
• Production Monitoring — Providing real-time visibility into production systems to compare planned versus actual performance

The value of plant floor data is clear. However, how that data is accessed and transported must be carefully architected to ensure it remains reliable, secure and useful. When not handled correctly, things can quickly go wrong.

The Pitfalls of Direct Integration: A Case Study

An engineer at a large manufacturing plant needed data from his Siemens PLC. With database experience in hand, he assumed a direct SQL connection would be straightforward. What started as a quick project quickly ballooned into a major effort, plagued by connection problems and timing issues.

His experience is far from unique.

Ten Reasons Direct PLC-to-Database Connections Fail

The simplicity of a direct PLC-to-database connection is appealing, but the architecture is fundamentally flawed for most production scenarios.

While each of the issues described below can be worked around individually, in combination they create a fragile, insecure and unmaintainable architecture that puts both your data collection efforts and your control system at risk.

1. Increased Cybersecurity Risk

   Under IEC 62443, the PLC resides in a control or production zone, while the database typically occupies a different zone with a different risk profile. The network path between them—an IEC 62443 conduit—must provide the security functions required for those zones to coexist safely. A raw TCP session from a PLC to a database does not meet this requirement, leaving the control system exposed to potential attack vectors.

2. PLCs Are Not Data Servers

   Although many PLCs offer SQL connectivity options, these features are typically difficult to implement and troubleshoot, with limited diagnostics. PLCs are engineered to control I/O, not manage database communications. They lack the capabilities expected of data servers like security logging, alerting, credential rotation and certificate lifecycle management.

3. PLC Scan Time and Control Risk

   Database drivers consume PLC processing resources. Under load, control performance can degrade. A database connection that works reliably today may produce intermittent communication failures tomorrow if the PLC application changes. Adding more tags, machines or users often further degrades performance, putting the primary control function at risk.

4. No Metadata Support

   Few PLCs provide the ability to supply or attach metadata—units, data types, engineering ranges—that upstream systems require to properly interpret and consume the data. Without metadata, downstream applications must rely on external documentation or manual configuration, both of which are error-prone and difficult to maintain.

5. No Scaling or Normalization

   Raw PLC data is often not formatted for upstream analytic systems. Custom PLC logic is required to normalize and scale the data, placing that responsibility on the PLC programmer. PLC programmers should not be responsible for formatting data consumed by enterprise and cloud applications.

6. No Data Modeling

   Modern analytic systems rely on structured data models to properly consume information. Most PLCs lack the capability to compose data models or schedule their transfer to databases and upstream systems in a structured, consistent manner.

7. No Timestamping

   Many PLCs cannot timestamp the data they deliver to the database. Time-series data is effectively useless without an accurate timestamp that reflects when the event actually occurred, not when the data was transmitted or stored.

8. No Operational Context

   Whether a machine is running, stopped, jogging or in an error state, system context is critical for interpreting PLC data correctly. PLCs typically represent these states as integers, but the corresponding enumerations often don’t exist within the PLC itself and cannot be stored meaningfully in the database.

9. Brittle Error Handling

   Network drops, database locks and schema changes can all inhibit data access, leading to stalled writes or silent data loss. Without intermediate buffering, there is no recovery mechanism. Data gaps may go undetected for extended periods, undermining the reliability of the entire data collection effort.

10. Poor Data Scheduling Control

    Most PLCs lack the ability to publish data on configurable schedules. Production environments require flexible scheduling options—hourly, at shift end, end of day, end of job—as well as cyclic writes and change-of-value triggers. These capabilities are simply absent from typical PLC platforms.

When Direct Connections May Be Acceptable

On the surface, a direct PLC-to-database connection is attractive, offering low latency, no middleware and a straightforward architecture. In certain constrained scenarios, it can be a reasonable choice, provided the following conditions are all met:

• Low tag counts — Fewer tags mean fewer PLC resources consumed by database communications and less risk of interfering with normal operation.
• Slow update rates — Slower rates similarly reduce resource consumption and operational risk.
• Non-critical data only — Without intermediate buffering, link failures or database errors mean permanent data loss. Only non-critical data should be transferred directly.
• Short system life — Prototype or temporary data collection efforts, with the important caveat that “temporary” very often evolves into “permanent.”

Violating any of these conditions increases the risk to both your data collection efforts and your control system’s operation. When in doubt, use an intermediate layer.

Recommended Architectures

Instead of connecting a PLC directly to a database, architect your data collection solution to optimize security, flexibility and maintainability. The following table compares the three primary architecture patterns, ranked from most to least recommended.

A useful rule of thumb: Use edge gateways to optimize data movement and normalization. Use historians to optimize time integrity and lossless capture.

Use a Historian to Collect and Publish PLC Data (Recommended)

Position a local historian in the same zone as the PLC and have it push time-series data to the database. This is the recommended architecture for production environments. Benefits of this architecture include:

• Optimization for continuous, high-frequency data ingestion with accurate timestamping
• Local buffering with store-and-forward capability
• PLC tag auto-discovery
• Scaling and normalization
• Support for MQTT, OPC UA, REST and other standard IT and factory protocols.

The primary tradeoff is the cost of purchasing and maintaining the additional historian component. For plant-floor deployments, note that the historian is often a dedicated device rather than a Windows computer, and its storage capacity must be sized appropriately for the volume and frequency of data being collected.

The RTConnect PLC Historian

To simplify this architecture, RTA offers the RTConnect Historian for Allen-Bradley PLCs. This dedicated hardware solution eliminates the headache of PC-based historians by providing a ruggedized, plug-and-play gateway between your tags and your database.

The RTConnect Historian is available in three distinct storage tiers to ensure you aren’t paying for overhead you don’t need. To determine which model fits your application, use our storage tier calculator and view application examples.

Use a Security Device or Edge Gateway

Position a security device—ideally one that functions as an IEC 62443 secure conduit—or an edge data collection device between the PLC and the database. This architecture provides a cybersecure interface between the machine process and the enterprise application. However, it does not resolve the lack of timestamping, scaling, normalization or data scheduling inherent to the PLC.

If using a firewall in this architecture, enforce strict allow lists for IP addresses, ports and direction. Configure authorization rules with no general routing. The firewall enforces zone separation and provides defense-in-depth.

Future-Proofing Your Plant Floor Data Pipeline

There is significant value in storing PLC data in a database, but only when that data is properly scaled, accurately timestamped and reliably delivered. Connecting a database directly to a PLC is usually a flawed architecture, even when it appears to work in a quick pilot.

Direct connections increase cybersecurity exposure, consume PLC resources that should be dedicated to control and create silent data-loss modes during network drops, database locks and schema changes. They also miss core data needs such as reliable timestamping, buffering, scheduling, normalization, metadata and diagnostics. Reserve direct PLC-to-database connections for low tag counts, slow update rates, non-critical data and short-lived prototypes—and only with strict zone separation.

For production systems, insert a secure conduit with an edge gateway, or better yet, a local historian between the PLC and the database. The additional investment pays for itself in reliability, security, and long-term maintainability.

About the Author