Ignition Historian Configuration and Tuning
Key Takeaway
How to configure and optimize the Ignition Tag Historian for performance, storage efficiency, and long-term data retention in industrial SCADA environments.
Quick Answer
The Ignition Tag Historian stores time-series data in a SQL database (SQL Server, MySQL, PostgreSQL, or MariaDB). Effective historian tuning involves configuring appropriate deadbands to reduce unnecessary writes, setting retention policies to manage database growth, optimizing SQL indexes for query performance, and using partitioning strategies for large datasets. NFM's managed Ignition SCADA services include ongoing historian performance management.
Historian Architecture Overview
Ignition's Tag Historian module writes tag value changes to a relational database through configurable history providers. Unlike some SCADA platforms that use proprietary file-based historians, Ignition by Inductive Automation leverages standard SQL databases, making data accessible to any SQL-capable tool — BI platforms, custom applications, and reporting systems.
Deadband Configuration
Deadband settings control how much a tag value must change before a new historical record is written. Proper deadband configuration can reduce database write volume by 60–80% without losing meaningful operational data. Setting deadbands too tight wastes storage; setting them too loose loses important process trends.
- Analog tags: Set deadband to 0.5–2% of the tag's expected range
- Boolean tags: No deadband needed (state changes are always significant)
- Counter tags: Consider rate-of-change deadbands rather than absolute value
Retention and Partitioning
Large Ignition historian databases benefit from table partitioning strategies that separate recent data (hot) from historical archives (cold). SQL Server partitioning by month or quarter allows efficient purging of old data without impacting query performance on recent records.
SQL Performance Tuning
Key SQL optimizations for Ignition Tag Historian databases include proper index maintenance, statistics updates, tempdb optimization, and connection pool sizing. NFM's managed SCADA services include scheduled database maintenance to prevent performance degradation over time.
Monitoring Historian Health
Ignition's gateway status page provides real-time metrics on historian write throughput, queue depth, and error counts. A healthy historian shows consistent write rates, minimal queue backlog, and zero persistent errors. Sustained queue growth indicates the database cannot keep up with write volume and requires immediate attention.
Frequently Asked Questions
Microsoft SQL Server and MySQL are the most common choices. SQL Server is preferred for large enterprise deployments due to its partitioning, compression, and high-availability features. MySQL works well for smaller installations. PostgreSQL is also supported and growing in popularity.
Storage requirements depend on tag count, scan rate, and deadband settings. A typical 10,000-tag system with 1-second scans and proper deadbands generates roughly 10–50 GB per year. Without deadbands, that same system could generate 500+ GB annually.
Yes. Because Ignition stores historian data in standard SQL databases, any tool that can connect to SQL Server, MySQL, or PostgreSQL can query the data directly. This includes Power BI, Grafana, Python analytics scripts, and enterprise reporting platforms.