An OPC UA server exposes live process data as a structured address space, but that data lives only in the server's memory and moves only to clients that subscribe to it. To keep a durable history, feed reports, or let other applications query the values, the data usually has to land in a relational database. OPC UA to SQL integration is the pattern that connects the two: a connector subscribes to the OPC UA server, receives value changes as they happen, and writes them into SQL tables, mapping each OPC UA node to a place in the database. Doing this well means more than dumping numbers into rows; it means carrying the source timestamp and quality, choosing between inserting a history and updating a current value, and protecting against the database being unavailable. This guide explains how the mapping and batching work, how deadbands and timestamps are handled, the difference between a direct writer and a store-and-forward buffer, and where cloud SCADA removes the need to run this bridge at all.
OPC UA to SQL Database Integration in one line: OPC UA to SQL database integration is the pattern of piping data from an OPC UA server into relational SQL tables, typically by subscribing to nodes with monitored items and writing each value change to the database. A connector maps each node's NodeId to a target table and column, batches the incoming changes into efficient inserts or upserts, applies deadbands so trivial fluctuations are not written, and preserves the source timestamp and quality code rather than substituting the moment of insertion. It can run as a direct client that writes straight to SQL or as a store-and-forward buffer that holds data through a database outage, and cloud SCADA can remove the need to build and run such a bridge yourself.
The core of an OPC UA to SQL connector is a mapping from the OPC UA address space to the database schema. Every value in an OPC UA server is identified by a NodeId, and the connector needs to know, for each NodeId it cares about, where that value should go in SQL: which table and which column, or in a narrow-table design, which tag identifier to record alongside the value. This tag-to-column mapping is the configuration that turns a stream of node updates into structured rows a query can make sense of. It can follow a wide layout, where each node becomes its own column in a row per timestamp, or a narrow layout, where each reading becomes a row carrying a tag identifier, a value, a timestamp, and a quality, with the wide layout easier to query for a fixed set of tags and the narrow layout more flexible as tags come and go.
The connector gets the data by subscribing rather than polling. It creates an OPC UA subscription and adds a monitored item for each node it wants, and the server then pushes a notification whenever a monitored value changes, so the connector receives changes as they occur without repeatedly asking. This is far more efficient than reading every node on a timer, because quiet values generate no traffic and no database writes, while active values are delivered promptly. The subscription model is what makes an OPC UA to SQL feed scale to many tags without hammering either the server or the database with constant reads.
Writing each individual value change to SQL as its own statement would overwhelm a busy database, so a good connector batches. It collects the value changes that arrive over a short window or up to a count and writes them to the database in a single batched operation, which is dramatically more efficient than one round trip per value. Batching trades a small amount of latency, the values wait briefly to be grouped, for a large gain in throughput and a much lighter load on the database. Sizing the batch and the flush interval is one of the tuning decisions in an OPC UA to SQL integration, balancing how fresh the database needs to be against how much write load it can take.
A monitored item can be configured with a deadband, which tells the server not to report a change unless the value has moved by more than a set amount. This matters for a SQL feed because analog values jitter constantly, and without a deadband a noisy signal would generate an endless stream of tiny changes and fill the database with meaningless rows. A sensible deadband suppresses the noise so that only meaningful movements are reported and stored, which keeps the database smaller and the history more useful. Choosing the deadband is a judgement about how much resolution the history needs versus how much noise it can do without, and it is set per monitored item to suit each signal.
Preserving the source timestamp and the quality code is essential to a trustworthy feed and is a common place where naive integrations go wrong. Each OPC UA value carries a timestamp indicating when the value was actually valid at the source, and a quality or status code indicating whether the value is good, uncertain, or bad. A connector must write those into the database rather than substituting the time the row happened to be inserted or discarding the quality, because the insertion time can lag the real time and a bad-quality value that is stored as if it were good corrupts any analysis built on the history. Carrying the source timestamp and the quality through to SQL keeps the database an honest record of what the process actually did and when, and lets downstream users filter out or flag the values that were not trustworthy.
The connector also has to decide between inserting and upserting. Inserting a new row for every change builds a time-series history, which is what a historian wants, so that the full sequence of values over time is preserved. Upserting, meaning updating a row if a key already exists and inserting it otherwise, maintains a current-value table where each tag has one row that always holds its latest value, which is what an application wanting the present state wants. Many integrations do both, appending to a history table and upserting a live-value table, because the two serve different needs. Getting this right, and getting the key that identifies a row right, is central to whether the database ends up as a clean history, a correct snapshot, or a muddle of the two.
The simplest OPC UA to SQL connector is a direct writer: it subscribes to the server and writes straight to the database as changes arrive. This works well when the database is reliably available, but it has a serious weakness, which is that if the database goes down or becomes unreachable, the connector has nowhere to put incoming values and the data is lost for the duration of the outage. For a custody or operational history, a gap during a database outage is exactly the kind of hole that causes problems later, so a direct writer alone is risky wherever the data genuinely matters and the database cannot be assumed always up.
A store-and-forward design addresses this by buffering. Instead of relying on the database always being there, the connector writes incoming values to a local buffer or queue and forwards them to SQL when the database is available, holding onto them through an outage and flushing the backlog once the connection returns. This protects against database downtime, network interruptions, and maintenance windows, so that a temporary loss of the database does not become a permanent loss of data. The cost is added complexity, because the connector now has to manage a durable local store, handle the backlog on recovery without overwhelming the database, and keep the ordering and the timestamps correct, but for data that must not be lost the store-and-forward pattern is the responsible choice over a bare direct writer.
All of this is real engineering that someone has to build, run, and maintain, and this is where a cloud SCADA platform changes the picture. A platform such as Merobix can connect to an OPC UA source and ingest its data into a managed, durable store directly, handling the subscription, the timestamp and quality preservation, the buffering through connectivity gaps, and the historical storage as part of the service, so the operator does not stand up and babysit a separate OPC-UA-to-SQL bridge and its database. The store-and-forward protection against outages and the retention of source timestamps and quality become properties of the platform rather than code the operator writes and supports. For an organisation whose goal is a reliable historical record and remote visibility rather than a bespoke integration to maintain, letting the cloud SCADA layer own the path from OPC UA to durable storage removes an entire class of connector and database plumbing, along with the failure modes that come with running it.
A connector subscribes to the OPC UA server, adding a monitored item for each node it wants, and the server pushes a notification whenever a monitored value changes. The connector maps each node's NodeId to a target table and column, batches the incoming changes for efficiency, and writes them to SQL, preserving the source timestamp and quality. Using subscriptions rather than polling means only actual changes generate writes, which keeps the load on both the server and the database manageable.
Each OPC UA value carries a timestamp for when it was actually valid at the source and a quality code saying whether it is good, uncertain, or bad. If the connector substitutes the insertion time, the history no longer reflects when the process actually did something, and if it discards the quality, a bad or uncertain value gets stored as if it were trustworthy. Carrying both through to the database keeps it an honest record and lets downstream users filter out values that should not be relied on.
A direct writer subscribes and writes straight to the database as changes arrive, which is simple but loses data if the database goes down or becomes unreachable, since there is nowhere to put incoming values during the outage. A store-and-forward connector buffers incoming values locally and forwards them once the database is available again, so a temporary database or network outage does not become a permanent data gap. Store-and-forward is more complex but is the responsible choice wherever the data must not be lost.
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.