Tag history or a transaction group?

The split Inductive Automation draws

The recommendation is stated plainly in the documentation: for continuous processes, use tag history. For discrete processes, use SQL Bridge.

A continuous process is a continuous amount of material, where the concern is consistency of production. A discrete process is a specified count of units moving from workstation to workstation to be modified. Flow, pressure and temperature on a treatment train are continuous. Parts through a cell, batches through a line, units through test are discrete.

Why the split exists: how each one stores time

The recommendation follows from a mechanical difference worth understanding, because it is what actually decides borderline cases.

Tag history stores asynchronously. Each tag is stored independently — one tag might be written every ten seconds because it changes constantly, while another is written twice a day because it does not. That is efficient, and it is the right shape for continuous measurement, where each signal has its own natural rhythm.

A transaction group stores synchronously. All items in the group are stored together as a single SQL transaction. Every value in that row shares one timestamp and one execution.

So the question that resolves most cases is: do these values need to land in one row, under one timestamp, tied to a countable thing? If a part completing test should produce one record carrying its ID, its result, its cycle time and the operator, that is a transaction group, and no amount of tag history assembles it cleanly afterwards. If you are recording twelve independent signals that happen to be near each other, that is tag history.

Inductive Automation is careful to note that most industries involve both. Their worked example is water and wastewater: continuous flow measurement alongside discrete pump starts and tank alarms. The split is a guide to each dataset, not a label for the whole site.

The second question

After process type, the thing that most often decides it is who reads the table.

A transaction group gives you a customisable table structure and direct SQL querying, which matters when an ERP, a report writer or somebody’s existing query has to consume the data in a shape you do not control.

Tag history has a fixed table structure, and each history provider manages its own storage configuration and schema. The layout is documented and Inductive Automation markets the storage as open rather than proprietary, so “you cannot read it” would be too strong — but IA’s own guidance is to query it with Ignition’s built-in tools rather than reaching into the tables, and the schema remains theirs to change.

Provider choice matters here more than it used to. On 8.3’s Core Historian the data lives in an embedded store on the gateway rather than as tables in your SQL database, so an outside reader goes through an interface you have to enable and configure, not a plain database connection. That is a more concrete reason to plan external access deliberately than any argument about schema stability.

What a transaction group actually is

Transaction groups are the heart of the SQL Bridge module — execution engines that perform database tasks such as storing data historically, synchronising database values to a device, and loading recipe values. There are four types.

• Historical — one-way, logging one data point per item to a column, aside from trigger resets and handshakes.
• Standard — two-way, able to log to the database or read from it and write to OPC items or tags.
• Block — a standard group whose every execution can handle multiple rows rather than one.
• Stored Procedure — invokes a stored procedure and returns its OUT and INOUT parameters to tags or OPC items.

The two-way capability is the most commonly overlooked. Reading from a database and writing to tags is how recipe loading works, and tag history has no equivalent.

Two settings that are easy to conflate

Update Mode sets the direction data flows: OPC to DB, DB to OPC, or bi-directional with either side winning. Table Action decides what happens to rows — whether an execution inserts a new row, or selects and updates the first, last or a custom record.

They are separate settings and they get confused, which produces a table that looks correct in testing and wrong in production. Both apply to Standard and Block groups. A Historical group has no Table Action at all, and its Update Mode is effectively fixed at OPC to DB, since it only inserts and cannot write back to OPC items. Decide both deliberately.

What you are actually taking on

Choosing a transaction group is less work than it once was, and less than the “you have to build it all yourself” reputation suggests. SQL knowledge is not required to run one; a group can automatically create and modify its table on startup, and a “delete records older than” setting prunes by age so tables do not grow unbounded. Since 8.1 there has also been a DB Table Historian Provider, specifically so a table created by a transaction group can be read by tag history bindings and the Power Chart — though that provider is read-only, and Inductive Automation notes its setup is more involved than other historian types, needing column, timestamp and path mappings configured before it works.

What remains yours is the ownership. The schema, the retention decision and the query surface are now things you decided and must maintain, rather than things the historian handled. If nothing outside Ignition reads the table and the values do not need to share a row, that ownership buys very little.

One practical note for anyone comparing: transaction groups require the SQL Bridge module, so “which do we have licensed” is a fair question to ask before the architectural one.

Two things worth knowing before you build

Transaction groups go through store and forward, and so does tag history bound for a SQL historian, so both inherit its behaviour during a database outage. Ignition 8.3’s Core Historian is the exception: it writes directly to disk with a write-ahead log and does not use store and forward at all. We covered what that buffer does and does not cover in what happens when the database goes away.

And a reasonable default: start with tag history unless the values need to share a row and a timestamp, or something outside Ignition needs a table shape you control. Those are real needs and SQL Bridge exists for them — they are narrower than habit tends to assume.

Common questions

References

• Inductive Automation — Tag History vs. Transaction Groups
• Inductive Automation — SQL Bridge (Transaction Groups)
• Inductive Automation — Types of Groups: Table Action and automatic table creation
• Inductive Automation — Transaction Group Update Modes
• Inductive Automation — Tag History Providers
• Inductive Automation — DB Table Historian Provider
• Inductive Automation — Historian Core Module: open SQL storage
• Inductive Automation — Historian