A database connector is the SCADA component that reads from and writes to an external SQL database. It is how a SCADA system logs a production record into a plant database, queries a recipe or setpoint table on demand, or triggers an insert when an event occurs. Unlike the historian, which stores time-series data in its own optimized store, a database connector reaches out to a general-purpose relational database that other business systems also use, making SCADA a participant in the plant's broader data.
Database Connector in one line: A SCADA database connector is a component that exchanges data with an external SQL database. It writes records such as production totals or event logs on defined triggers, and reads data such as recipes and setpoints back into the SCADA system. It typically uses ODBC or JDBC, runs parameterized queries, and buffers with store-and-forward when the database is unreachable.
A database connector works around events and triggers rather than continuous streaming. A write might fire when a batch completes, when an alarm trips, or on a timed interval, inserting a row that captures the relevant tag values and a timestamp. A read might fire when an operator selects a product, pulling the matching recipe or setpoints out of a table and applying them to the process. The connector turns discrete process moments into database transactions and turns stored data into live process configuration.
This is a natural fit for structured, transactional records that belong in a relational database: production logs, quality results, downtime reasons, material consumption. These records are often shared with reporting tools, ERP systems, and analysts who query SQL directly, so writing them into a proper database rather than only a historian makes them broadly usable. The connector is the bridge between the real-time process and the relational world.
Connections are typically made over ODBC or JDBC, the standard interfaces for reaching SQL databases. ODBC is common on Windows-based SCADA, and JDBC on Java-based platforms, but both give the connector a vendor-neutral way to talk to SQL Server, Oracle, PostgreSQL, MySQL, and others. The connector configures the connection string, credentials, and the queries it will run against the target.
A database can be unavailable exactly when SCADA needs to write to it, so a good connector implements store-and-forward. If the database is down or the network is broken, the connector queues the pending writes locally and forwards them once the connection returns, rather than dropping the records. Without this, a maintenance window on the database server quietly loses production data. Store-and-forward turns an outage into a delay instead of a loss.
Security matters because a database connector executes queries against a real database, often with write privileges. The connector should use parameterized queries rather than building SQL by concatenating tag values into a string, because concatenation opens the door to SQL injection, where an unexpected value alters the query's meaning. Parameterized queries keep data and command strictly separate. The connector should also run with least-privilege credentials, able to touch only the tables it needs.
Ordering and idempotency deserve thought too. If store-and-forward replays a queued write after a reconnect, the system should not create duplicate rows for the same event. Designing writes so a replay is safe, for example by including a unique event key, keeps buffered retries from corrupting the record.
It is important not to confuse a database connector with the historian's own storage. The historian is purpose-built to store high-rate time-series tag data efficiently, with compression and time-based retrieval. A database connector, by contrast, talks to a general relational database holding structured business records that many systems share. You use the historian to trend a tag over months, and the connector to write a production summary row that the ERP and reporting tools will read.
In field operations, the connector is often what links SCADA to plant or corporate databases where operations, maintenance, and finance data live together. A completed run posts a record; a shift report reads back yesterday's totals; a recipe table drives the next batch. These are relational, transactional interactions, distinct from the continuous logging the historian handles.
In a cloud SCADA architecture, this connector role can be provided centrally so each site does not maintain its own fragile database link. As cloud SCADA for oil and gas and other industries, Merobix collects field data and can expose it to downstream databases and applications through managed, secure interfaces, applying store-and-forward and safe query practices consistently rather than leaving each site to hand-build a connector that may skip those safeguards.
The historian is a purpose-built store for high-rate time-series tag data, optimized for trending and time-based queries. A database connector talks to a general relational database holding structured records shared with other systems. You trend a tag in the historian and write a production summary row through the connector.
It is a buffering behavior that protects data when the database is unreachable. Instead of dropping writes during an outage or network break, the connector queues them locally and forwards them once the connection is restored. This turns a database maintenance window into a delay rather than lost production records.
Because the connector runs queries built partly from tag values, and if it builds SQL by pasting values into a string, an unexpected value can change the query's meaning, a flaw known as SQL injection. Parameterized queries keep the data separate from the command, so no input can alter the query's structure. They are the safe way to pass values.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.