Which Data Sources Timebase Supports, and How Each One Reaches Atlas
Which data sources Timebase supports, which component connects to each one, and how to reach a source that has no direct connector.
Overview#
"Does Timebase support MQTT?" has a yes answer, but not a one-word one, because Timebase is several components and they connect to sources in different ways. This article maps every supported source to the component that handles it and the path the data takes to reach Atlas.
Read it if you are evaluating Timebase against a list of protocols, or if you know which source you have and want to know where to start.
The one sentence version: Atlas connects directly to historians, SQL databases, OPC UA, i3X and HTTP APIs. Broker and edge protocols such as MQTT and Sparkplug B are handled by the Timebase Collector, which stores into the Timebase Historian, and Atlas connects to that Historian. Both are supported, designed paths.
Find your source#
| Your source | Component that handles it | How it reaches Atlas |
|---|---|---|
| MQTT (plain topics, JSON or primitive payloads) | Timebase Collector | Collector stores to Historian; Atlas connects to the Historian |
| MQTT Sparkplug B (including a UNS) | Timebase Collector | as above |
| OPC UA | Either. Collector for store-and-forward history, or the Atlas OPC UA connector for a direct read | Collector path, or direct |
| Telegraf / InfluxDB line protocol | Timebase Collector | Collector stores to Historian; Atlas connects to the Historian |
| Ignition | Timebase Historian Module for Ignition | Ignition historises to the Historian; Atlas connects to the Historian |
| Timebase Historian | Atlas connector | direct |
| SQL Server, PostgreSQL, MySQL, Oracle | Atlas connector | direct |
| AVEVA Historian, AVEVA PI System, CanaryLabs | Atlas connector | direct |
| CESMII i3X | Atlas connector | direct |
| Flow InfoHub | Atlas connector | direct |
| Any HTTP or REST API | Atlas connector | direct |
| Anything you can write yourself | Historian REST API | write to the Historian; Atlas connects to it |
The two paths, and why both exist#
Direct: an Atlas connector#
A connector is a separate component that connects outward to Atlas over a live connection and advertises which data points it can serve. You then reference those points by binding path. Atlas holds no copy of the data; values arrive as the source produces them.
The twelve shipped connectors are Timebase.Historian, OPCFoundation.OpcUa, CESMII.I3X,
Microsoft.SqlServer, PGDG.PostgreSql, Oracle.MySql, Oracle.Database, Aveva.Historian,
Aveva.PiSystem, CanaryLabs.Historian, InfoHub and IETF.Http.
Choose this path when the source is already a queryable system of record.
Via the Collector and Historian#
The Timebase Collector subscribes to edge and broker protocols and stores what it receives in the
Timebase Historian. Atlas then reads that Historian through the Timebase.Historian connector.
This is not a workaround for a missing connector. It is the right architecture for streaming sources, and it buys you two things a direct subscription cannot:
- Store and forward. The Collector buffers when the Historian is unreachable and forwards on recovery, so a network interruption does not lose data.
- Real history. The values are stored, so Atlas can serve historical ranges and not only the latest value.
Choose this path for anything that publishes rather than answers queries.
What the Collector actually supports#
Five plugins ship. Each has its own published configuration guide.
| Plugin | What it does |
|---|---|
| MQTT | Subscribes to MQTT topics carrying plain payloads: JSON objects, or simple primitives such as numbers, booleans and strings. Supports topic wildcards. |
| SparkplugB | Implements MQTT Sparkplug B v1.0 on the spBv1.0 namespace, including the full message set: NBIRTH, DBIRTH, NDATA, DDATA, NDEATH and DDEATH, with metric handling. |
| OPCUA | Connects and subscribes to tags in an OPC UA server. |
| Telegraf | Runs as a WebSocket server accepting connections from Telegraf agents using the WebSocket output plugin, parsing InfluxDB Line Protocol and creating tags from measurements and fields. |
| Simulator | Generates simulated historical data from real-world process models, for demos and testing. |
On unified namespace (UNS)#
A UNS is normally built on MQTT with Sparkplug B, and that is exactly what the Collector's SparkplugB plugin implements. The parts that matter for a UNS are present:
- Birth and death certificates (
NBIRTH,DBIRTH,NDEATH,DDEATH), which is what lets consumers discover structure and detect loss of a publisher rather than inferring it from silence. - Metric-level handling, so individual metrics within a payload become individual tags.
- Topic wildcards in the plain MQTT plugin, for subscribing across a topic hierarchy.
So a UNS can act as a Timebase source. Where Timebase sits in your architecture is a design decision: the Collector consumes the namespace and historises it, and Atlas then adds the semantic model over the top. On the outbound side, Bridge's Sparkplug B plugin publishes Atlas values back into a Sparkplug UNS as a proper Sparkplug session, with birth certificates, aliases and death handling, so Atlas can take part in the namespace rather than only read from it. See Sparkplug B Bridge Plugin.
Writing directly to the Historian#
If you have a source nothing above covers, the Historian REST API lets you create and configure datasets and tags and write tag data yourself. That is the general escape hatch: get the data into the Historian by any means you like, and Atlas connects to it exactly as it would to any other Historian.
The Historian also exposes read-side interfaces that matter for interoperability: a REST API, WebSocket subscriptions for live tag updates, Server-Sent Events streaming, and the CESMII i3X API.
Outbound: getting data out of Atlas#
Sources are only half of an integration question. Atlas exports through Bridge, which subscribes to
the Atlas value hub and writes to a destination. Nine plugins ship: Microsoft.SqlServer,
PGDG.PostgreSql, Oracle.MySql, MQTT, Eclipse.SparkplugB, Apache.Kafka, Microsoft.EventHubs,
Snowflake.SnowpipeStreaming and IETF.Http. See Exporting Data with Bridge.
Note the asymmetry, because it catches people out: Kafka is an outbound destination, not an inbound connector. Atlas can publish to Kafka. Nothing in Timebase consumes from Kafka today. MQTT runs both ways, but through different components: the Collector consumes it, Bridge publishes to it.
Atlas itself also exposes a REST API, an MCP server for AI agents, and SignalR hubs for live values.
What is not supported today#
Stated plainly, because a clear no is more useful than a vague yes:
| Source | Status |
|---|---|
| Kafka as an input | Not supported in any component. Supported as a Bridge output only. |
| CSV or Excel files | No file connector in Atlas or the Collector. |
| Generic event streams (webhooks inbound, AMQP, NATS, and similar) | No connector. The HTTP connector polls an endpoint, and optionally consumes SSE; it does not receive pushed webhooks. |
For any of these, the escape hatch above applies: land the data in a Historian or a SQL table by your own means, and connect Atlas to that.
Related articles#
- Connecting Data Sources
- How Binding Works: Properties, Instances and Data Sources
- Exporting Data with Bridge
- Timebase Atlas Architecture
- The per-plugin connector and Bridge articles, one for each of the twenty-one plugins
For the Collector plugins, see the published guides: Configuring The MQTT Data Collector, Configuring The MQTT SparkplugB Collector, Configuring The OPC UA Collector, Configuring the Telegraf Data Collector, and Store And Forward Operation.