A quick note on where this comes from: I'm not writing this from a developer's chair. I don't live in the scripting console all day, and I won't pretend to. What I do have is years of exposure to real-world IIoT and automation systems — seeing what's been built, where it holds up, where it falls over, and talking to the integrators who live inside Ignition every day. This is the pattern that keeps coming up. Take it as field-earned experience, not a formal spec — and if you're a developer who wants the exact mechanics, I've pointed to Inductive Automation's own docs at the end.

Every Ignition project eventually hits the same fork in the road: you've got a piece of data, and you have to decide where it lives. Does it go in a Tag, or does it go in a database?

Get it right and the system is fast, stable, and easy to live with. Get it wrong and you end up with a gateway choking on query tags, a historian bloated with values nobody ever trends, or — the one that really hurts — production records sitting in memory tags where they were never meant to be.

The good news: the call is almost always clear once you ask the right question. Here's that question, why it works, and a checklist you can actually use on your next build.

The one question that settles most of it

Ask this first: Is this the “now,” or is it the “record”?
  • A Tag holds the now — the current value of something, with its quality and timestamp. Tank level is 4.2 metres. Pump is running. Setpoint is 75°C.
  • A database holds the record — the things you need to keep, query, join, report on, or hand to another system later. The batch that finished at 14:32. The downtime event and its reason code. Who changed the setpoint, and when.

Tags answer “what is it doing?” Databases answer “what happened, and can you prove it?” Most data-placement mistakes are just this line getting blurred.

For what it's worth, this isn't just my take — Inductive Automation frames the same decision in its own material, splitting it along continuous versus discrete/event-based data: continuous processes lean on tag history; discrete, event-driven ones lean on the SQL Bridge. That's “now vs record” in the vendor's own words.

What a Tag is for

Tags are Ignition's real-time picture of your process. Whatever the type — OPC, Memory, Expression, Query, Reference, or Derived — a Tag carries a value, a quality, and a timestamp, and it represents live state.

Reach for a Tag when the data is:

  • A live process value — level, flow, temperature, pressure, motor state, counts. Usually an OPC Tag bound to a PLC or device through the OPC server.
  • Something you bind to an HMI — Perspective and Vision components bind to Tags for instant, event-driven updates. This is the fast path.
  • Driving alarms — Ignition's alarming works off live Tag values.
  • A quick read/write from a screen or a script — a setpoint you write down to a PLC, a mode selector, a command.
  • Calculated live state — Expression Tags compute a value; Derived and Reference Tags re-expose or transform another tag, all without touching a database.

Worth keeping straight on persistence: a Memory Tag holds its last value across gateway restarts, which makes it a fine home for a setpoint that has to survive a reboot. But it still holds one current value — not a history, and not a table. A Query Tag can even run a SQL query as its value; occasionally useful, but a common source of the over-polling trap further down.

What a Database is for

A database is where data goes when you need to keep it, structure it, and query it — often long after the moment it was captured, and often for systems other than Ignition.

Reach for a database when the data is:

  • History you need to query or report on — trends, shift reports, KPIs, dashboards.
  • A transactional / event record — a completed batch, a production count per hour, a downtime event with start/end/reason, a quality test result.
  • Relational — records that join to others (this batch → this product → this order → this operator).
  • An audit trail — who did what, when.
  • A large dataset, or data other systems consume — ERP, MES, BI/reporting tools.

There are three main ways to get data in and out of a SQL database in Ignition:

  • Named Queries — preconfigured, parameterised queries that run on the gateway, with access controlled by security zone and user role. This is the modern, recommended approach for both reads and writes. A practical tip integrators will tell you: use Value parameters wherever you can (they behave like prepared-statement values and stand up to SQL injection), and be careful with QueryString parameters — they're flexible enough to parameterise table and column names, but they aren't sanitised, so never wire them to free-form user input.
  • Transaction Groups — the workhorses of the SQL Bridge module. They log tag/OPC values into columns of a table you define, on a schedule or a trigger, in a few flavours (Historical, Standard, Block, Stored Procedure). Great for structured logging without much code.
  • Scripting — the system.db functions, when the logic gets custom and you want full control.

The overlap that trips people up: Tag Historian vs. a purpose-built DB

This is where the genuinely tricky calls live, because both options end up writing to a database — they just do very different jobs. (Inductive Automation actually publishes a dedicated “Tag History vs. Transaction Groups” comparison — linked at the end — and it's worth ten minutes.)

Tag Historian

The Tag Historian module logs tag value changes to a database automatically — you tick a box on the tag — and its engine handles compression, partitioning, interpolation, and aggregation for you. Behind the scenes, samples run through a store-and-forward pipeline, and whether a given change gets stored comes down to three settings: Sample Mode (On Change / Periodic / Tag Group), a min/max timer, and deadband. You pull the data back by time range and tag path, pick an aggregation mode (min / max / average and so on), and the historian slices and interpolates it for you.

Lean on Tag Historian when:

  • You want time-series history of a live value — trends of temperature, level, flow, current.
  • You want it cheap to set up and cheap to store — deadband and sample modes keep the volume sane.
  • You mostly consume it as trends inside Ignition.

The trade-off, and IA is upfront about this: the historian uses its own tall, time-series-shaped tables. Brilliant for trends — but it's not a general-purpose relational store you'd join to business data or bend into a report layout.

A purpose-built DB schema (Named Queries / Transaction Groups / scripting)

When you need relational, transactional, or reporting-shaped data, define your own tables and write to them on purpose. The payoff is exactly what the historian gives up: a schema you control, easy to read and join, that other systems can consume.

Go purpose-built when: the data is a structured record (one row per batch, event, or test), you need to join it to products/orders/operators, other systems read it, or you want precise control over what's written and when.

The rule of thumb

Rule of thumb: Continuous value you'll trend? → Tag Historian.  Discrete event or transaction with related fields under one timestamp? → Transaction Groups or a purpose-built schema.

Plenty of good systems do both: the live tank level is historised for trending and the finished batch (with its average level, product, and operator) is written as a transactional row for reporting. That's not duplication — it's two different questions answered by two different tools.

Anti-patterns to avoid

These are the ones I've seen come back to bite people:

  1. Using tags as a database. Concatenating records into a string tag, or growing a dataset memory tag row by row. A tag holds one value, not a queryable record set. If it's a record, it belongs in a table.
  2. Storing high-volume history only in tags. A single tag gives you one value; history belongs in the historian or a DB.
  3. Using Tag Historian for transactional/relational records. Forcing batch records or downtime events into the historian's time-series tables makes reporting and joins painful — that's exactly what Transaction Groups are for.
  4. Over-polling the database for values that should be live tags. A Query Tag hammering the DB on a fast rate for a value the PLC already publishes over OPC is avoidable load and lag. If the device has it live, read it as an OPC Tag.
  5. Historising everything “just in case.” Every historised tag costs storage and write throughput. Use Sample Mode and deadband deliberately; historise what you'll actually trend or report on.
  6. Hand-building SQL from concatenated strings. Use Named Queries with Value parameters instead of stitching query text together yourself.

The decision checklist

Run any piece of data through these:

  1. Need the current value now, for display/alarm/control? → Tag (OPC if it comes from a device).
  2. Need to see how a continuous value changed over time, mostly as a trend in Ignition? → Tag + Tag Historian.
  3. Is this a discrete event or transaction you'll query, join, or report on? → Database, purpose-built schema (Named Queries / Transaction Groups).
  4. Does another system need to read this in a known structure? → Database.
  5. Need to prove who did what, when? → Database (audit table).
  6. Just a live setpoint/command/mode? → Tag (persist with a Memory Tag if it must survive restarts).

Answered “yes” to both a Tag question and a Database question? That's normal — use both, deliberately.

Three worked scenarios

1. Current tank level vs. tank-level history

  • Live level for the HMI and high-level alarm → OPC Tag, historised.
  • “Show me last week's level trend” → Tag Historian.
  • “Average level during Batch #4471 on the batch report” → that average belongs on the batch record row in your DB, written when the batch closes.

2. Setpoint vs. setpoint-change audit

  • The current setpoint the operator sees and edits → Tag (Memory Tag if it must persist, or written down to the PLC).
  • “Who changed the setpoint from 70 to 75, and when?” → an audit-table row written on the change event. A tag only knows the latest value; it can't answer this.

3. Live production count vs. production records

  • Parts made this shift, ticking up live on the dashboard → OPC/derived Tag.
  • “Production per hour for the last 30 days,” “output by product and line” → transactional rows via a Named Query or Transaction Group — discrete, structured, joinable, report-ready.

Performance, scalability, maintainability

  • Performance: Tags are event-driven live state; databases are transactional round trips. Don't put a DB round trip in the fast path of a live display when a tag will do.
  • Scalability: Deadband and Sample Mode keep historian volume in check; a purpose-built schema with proper indexes scales for reporting. Uncontrolled historising and row-by-row memory-tag “storage” don't.
  • Maintainability: Named Queries keep your SQL in one managed, gateway-run place; Transaction Groups are transparent and mostly code-free; historian config lives with the tag. Ad-hoc SQL scattered through scripts is the hardest thing to maintain — steer clear.

The bottom line

Ask “now or record?” — or, in Inductive Automation's terms, continuous or discrete?

  • The now — live values, state, alarms, HMI binds, commands → Tags.
  • The trend of a continuous value → Tag Historian.
  • The record — discrete events, transactions, relational/reportable data, audit trails → a purpose-built database schema via Named Queries or Transaction Groups.

Tags and databases aren't rivals. They're two halves of a well-built Ignition system — and knowing which half a given piece of data belongs to is one of the clearest signs of someone who's done this for real.

On versions: this reflects current Ignition (8.1 / 8.3). Transaction Groups need the SQL Bridge module and Tag Historian needs the Tag Historian module — both standard, but check what's installed on your gateway. Named Queries have been around since the 7.x line and are the recommended approach in 8.x.

Want the exact mechanics? Straight from Inductive Automation

  • Tags and tag types — the Ignition user manual (Platform → Tags)
  • Tag Historian — how it works and configuring history (Ignition Modules → Tag Historian)
  • SQL Bridge / Transaction Groups (Ignition Modules → SQL Bridge)
  • Named Queries (Platform → SQL in Ignition → Named Queries)
  • “Tag History vs. Transaction Groups” — IA's own decision guide (Tutorials & Helpful Tricks)
  • Inductive University has short, free video lessons on all of the above.