The Two Databases, and Why the Distinction Matters
Every standard installation has both, and they do different jobs.
| Holds | Options | |
|---|---|---|
| Configuration database | Configuration, users, events, audit records | Embedded H2 by default. PostgreSQL or MySQL for larger deployments |
| Time-series database | Point-value history | The built-in historian, enabled by default. ClickHouse or TimescaleDB as alternatives |
The built-in historian ships enabled. It installs and configures itself with the platform, so there is no separate database to procure or tune to start collecting history.
This is the distinction that catches people out. When a monitoring platform lists supported databases, that list usually refers to the configuration database only. It is not a list of historian options, and choosing PostgreSQL for configuration does not put point history into PostgreSQL.
One exception applies on the free tier. Mango Free does not include the time-series module, so point values are stored as rows in the general relational database instead. Everything below about the built-in historian applies to the standard and Enterprise packages.
How Retention Works, and What the Default Is
Point values are kept for one year by default. Events and alarms are kept for one year as well, under their own separate settings.
Retention is configurable at three levels, and they stack.
| Level | Applies to |
|---|---|
| Global setting | The whole instance |
| Per data source | Every point on one source |
| Per data point | An individual point |
Event and alarm retention is configured separately from point values, and can be broken out by event type and by alarm severity. A critical alarm can be kept longer than a routine status change.
Periods are set in hours, minutes, days, weeks, months or years. Hours and minutes were added in version 5.6.
Why Retention Is Not the Same Thing as Backup
These are different guarantees, and it is worth being precise about which one you are relying on.
| What it is | How long | |
|---|---|---|
| Retention | How long point values, events and alarms are kept in the historian | One year by default, configurable |
| Configuration backup | A nightly export of configuration only, in JSON. No point values | The last 10 files are kept, by count rather than by age |
| Database backup | A nightly full database backup | The last 10 files are kept, by count rather than by age |
Backups are kept by count, not by age. How far back they reach depends on how often they run, not on a retention period. Backups are for recovery. Retention determines how much history you can query.
Using ClickHouse or TimescaleDB Instead
Both are available as alternative historian backends through the radixTsl module, which ships in the standard bundle.
It is disabled by default, and it changes the procurement answer. An alternative backend is an externally provisioned database: you size it, run it and maintain it. That is the opposite of the built-in historian, and it is the reason most deployments do not use one.
| Backend | Provisioning | When it fits |
|---|---|---|
| Built-in historian | None. Enabled by default | The default at every deployment size |
| ClickHouse | You provision and run it | Large deployments, and where analytics at scale already run on it |
| TimescaleDB | You provision and run it | You already run PostgreSQL infrastructure and want history alongside it |
Retention moves with it. On ClickHouse or TimescaleDB, retention is configured at the database level and Mango by Radix IoT’s purge settings do not apply to data held there. A deployment that moves to an alternative backend moves its retention configuration out of the platform and into the database.
How Stored Data Is Aggregated
Rollups turn raw point values into summarised periods for reporting and trend queries.
| Count | Examples | |
|---|---|---|
| Numeric only | 12 | Average, minimum, maximum, sum, delta |
| Numeric and non-numeric | 7 | None, first, last, count, all, start, point default |
Nineteen in total. The seven in the second row work on non-numeric data as well, which matters for status, state and text points where an average is meaningless.
What Is Stored, and What Is Not
Mango by Radix IoT reads live values and stores them in its own historian. It does not retrieve historical records from devices or from third-party servers.
The practical version: your record begins when Mango by Radix IoT starts reading a point. If a connection drops, the values that occurred during the outage are not recovered afterwards, because the platform never held them.
This applies across protocols rather than to any one of them.
| Protocol | What this means in practice |
|---|---|
| BACnet | The present value of a Trend Log object can be read like any other object. Device log buffers are not retrieved |
| OPC UA | Live values through subscriptions and polling. Server history is never read, so a disconnect leaves a gap in the record |
| DNP3 | Events are polled on a normal cycle and that poll resumes after an interruption. There is no catch-up routine. Where an outstation still holds events in its own buffer some may arrive, but that is the device retaining them rather than Mango by Radix IoT reconstructing the outage |
If you need a complete record across an outage, the answer is connection resilience rather than backfill, because no monitoring platform can store a value it was never sent.
What the Storage Architecture Means at Scale
Industrial monitoring produces a lot of values. A site logging 100,000 points once a minute generates 144 million of them a day.
Platforms built on general-purpose databases slow down as that archive grows. The usual responses are to reduce polling frequency, discard older data, or limit how many points get connected in the first place.
Because the historian here is purpose-built for time-series rather than adapted from a general-purpose database, those responses are not necessary.
| You can | Rather than |
|---|---|
| Connect every system on a site | Selecting a subset worth monitoring |
| Retain history over long periods | Discarding older data to keep queries fast |
| Poll at the interval the equipment supports | Polling at the interval the database can survive |
This is also what makes a portfolio-wide view practical rather than theoretical. Showing one building well is a different problem from holding dozens of sites in a single view, with equipment from different manufacturers installed across two decades, and doing it without the system slowing down.
Radix IoT Angle
Mango by Radix IoT uses two databases: a relational one for configuration, users, events and audit records, and a separate purpose-built time-series database for point-value history. Both install with the platform in a standard deployment, so there is no database to procure, size or tune before monitoring can begin. The free tier is the exception and stores point values in the relational database instead.
Retention is one year by default for point values, and one year separately for events and alarms, configurable globally, per data source, or per individual point, in periods down to minutes. Backups are a different guarantee: nightly configuration and database backups keep the last 10 files by count rather than by age, so they are for recovery rather than for history.
ClickHouse and TimescaleDB are available as alternative historian backends and ship in the standard bundle, disabled by default. Choosing one means provisioning and running that database yourself, and retention configuration moves to the database level.
The platform reads live values into its own historian and does not retrieve historical records from devices or third-party servers, so the record starts when Mango by Radix IoT starts reading a point.