Ensure your historian is both secure and performant.

Forget that Timebase Historian is completely free.

Evalute the solution like you were paying for it. We are confident you will discover what thousands of others already have. Timebase provides the performance you need and the security you would expect from other solutions you pay hundreds of thousands of dollars for.

Then smile, knowing that invoice is never coming.

Beta Testers Needed For New Timebase Atlas & Bridge

+ Learn more about the new modules coming this summer and register

COMING JULY 2026

Timebase Atlas

Atlas connects to your historians, MES, LIMS, CMMS, ERP, and other data systems and applies object-oriented principles and knowledge graphs to the OT world, enabling flexible models that can be used to solve your most complex business problems. With a built-in websocket interface, Atlas itself functions as a Unified Namespace you can subscribe to directly.

Timebase Bridge

Bridge is a pipeline-driven integration engine that extends Atlas by delivering modeled data to systems that cannot subscribe directly.

Join the Beta
Learn about Atlas and Bridge
Data Collectors
Data Historian
Trending
Data Access

DATA COLLECTORS

Reliably store data from your manufacturing systems

Timebase data collection builds ontop of the industry standards you are already following. All Collectors feature Store and Forward with automatic data buffering and disk storage and can stream to multiple Timebase Historians simultaneously.

OPC UA

Connect directly to OPC UA servers to subscribe to tags and log to the Timebase historian.

Supports continuous sampling, event-driven updates, and data change notifications, ensuring that value changes are captured reliably and without polling overhead.

Sparkplug

Allows Timebase to ingest structured, typed, and stateful MQTT data based on the Sparkplug B specification.

It's designed for environments where reliable equipment state, accurate metric reporting, and minimal polling overhead are important.

MQTT

Connects directly to standard MQTT brokers to ingest high-frequency publish/subscribe data into the Timebase Historian.

Supports raw topic ingestion with flexible payload handling, making it ideal for lightweight devices, and systems that publish MQTT without Sparkplug structure.

Ignition

Integrates natively with Inductive Automation Ignition 8.3+ to stream tag history directly into Timebase using native Ignition configuration.

Designed for plants standardizing on Ignition, providing a simple, reliable path to long-term storage without additional gateways or polling load.

Telegraf

Allows Timebase to ingest metrics collected by Telegraf from IT, OT, and infrastructure systems and reliably store them.

Supports hundreds of input plugins, enabling unified storage of system, network, and application telemetry alongside operational time-series data.

REST API

Provides a fully documented interface to programmatically create and manage datasets, define and update tags, and write time-series data directly into Timebase.

Designed for custom applications and integrations where direct control, versioning, and repeatable data ingestion are required.

Store and Forward

When the network between a collector and the historian goes down, whether due to a connectivity outage, a historian maintenance window, or an unstable edge network, you don't have to worry about data loss. Timebase keeps collecting.

Should someone be interpreting data from a tag that is effected by store and forward buffering, they will be immediately notified that the Timebase Historian has lost the data feed with a 'null' value and an updated timestamp of the exact date and time that the feed was interrupted.

Every logging session maintains its own independent local buffer, writing incoming data to disk automatically. When the connection is restored, the collector replays all buffered data in sequence and resumes real-time logging without any manual intervention. No data is lost, no gaps appear in the historical record, and operations teams don't need to be involved in recovery.

Each session's buffer is isolated, so a disruption affecting one historian connection has no impact on other sessions running in the same collector.

Redundancy

A single logging session in Timebase can write to multiple historian instances simultaneously, each receiving its own independent data stream. This provides active-active write redundancy at the collection layer.

If one historian becomes unavailable, data continues flowing to the others uninterrupted. Store and forward ensures the offline historian is fully reconciled and caught up the moment it comes back online, with no data loss and no gaps. This architecture eliminates the need for custom middleware or external replication tools to achieve historian redundancy across sites or cloud environments.

By opting for acitve-active rather than a active-passive Timebase is able to avoid the risk of potentially corrupted data getting 'synched' between the primary and secondary historian instances.

You can also create redundant logging sessions, each session isolated to its own hardware with identical logging sessions being sent to the same historian. Timebase Historian operates on a 'first-in-wins' principal based on unique timestamps and will simply disregard the identical second timestamp/value pair when it arrives.

Security

Timebase supports encryption and authentication at every connection point. All collector-to-historian communication can be secured with TLS, and each historian target is configured independently, so edge-to-cloud and site-to-site paths can each have their own security posture.

For OPC UA environments, Timebase implements the full OPC UA security model, including message signing and sign-and-encrypt modes with configurable cryptographic policies and manages its own client certificate lifecycle.

For MQTT and SparkplugB brokers that require it, mutual TLS certificate authentication is supported alongside standard username/password credentials.

Centralized identity and access management is provided by Timebase Pulse, which issues tokens to collectors and controls historian access, giving organizations a single point of governance over who and what can write data.

Metadata

Timebase treats metadata as a first-class concern, not an afterthought. Every tag collected by the historian can carry Fields, key/value pairs that describe where the data came from. These Fields could be as basic as the enterprise, site, area, line, or machine information, or any other operational classification that matters.

Critically, Timebase can derive this metadata automatically from the structure of the data source itself, using a feature called Topic Definition to map each level of an MQTT topic path or OPC UA namespace into a named, semantic attribute. This means thousands of tags can be correctly classified at the moment of ingestion without manual entry per device.

Fields can also pull values directly from message payloads; capturing device IDs, serial numbers, or units of measure embedded in the data. Fields can also be updated on existing tags at any time from the historian UI without interrupting collection or requiring re-ingestion.

Data Collector FAQs

Can Timebase write to more than one historian simultaneously for redundancy?
Yes. Each logging session can target multiple historian instances at the same time. Each historian receives its own independent data stream. If one historian becomes unavailable, data continues flowing to the others, and store and forward ensures the offline historian is fully caught up when it comes back online. This makes active-active redundancy straightforward to configure without any custom middleware.
How does Timebase handle out-of-order or duplicate data from unreliable sources?
The collector handles ordering, deduplication, and compression automatically. For SparkplugB specifically, the collector uses the protocol's native sequence numbering to detect gaps and out-of-order delivery. For sources that don't conform strictly to sequencing rules, that validation can be relaxed per subscription. In all cases, these concerns are handled by the platform, not by the implementation team.
What data sources and protocols does Timebase support out of the box?
Timebase ships with collectors for OPC UA, MQTT (vanilla JSON), MQTT SparkplugB, Ignition by Inductive Automation, Telegraf, and a built-in data simulator for testing. A standalone module is also available for Ignition by Inductive Automation that runs natively on the Ignition platform without a separate collector process. An open plugin architecture allows the community and partners to develop additional protocol support beyond the built-in set.
We use multiple protocols across our facilities. Can Timebase handle that in a single deployment?
Yes. You run one collector instance per protocol, and each instance can manage multiple logging sessions. A single Timebase deployment can simultaneously historize data from OPC UA servers, MQTT brokers, SparkplugB gateways, and Telegraf agents; all writing into the same or separate datasets in the historian. There is no requirement to standardize on one protocol before adopting Timebase.
We're already running Telegraf across our infrastructure. Can Timebase integrate without replacing it?
Yes, and without reconfiguring your Telegraf agents. The Timebase Telegraf Collector exposes a WebSocket endpoint on port 8086, the same port Telegraf agents already use to send data to InfluxDB. Redirecting Telegraf output to Timebase is a single line change in the Telegraf configuration. Your existing Telegraf input plugins, metric collection schedules, and tag enrichment all carry over intact.
Does Timebase support cloud, on-premises, or hybrid deployments?
Yes to all three. Timebase runs on Windows (via installer) or in Docker containers, making it deployable on bare metal, VMs, or cloud infrastructure. Docker support means you can run collectors at the edge (close to the data source) and target a historian running in the cloud or a data center. TLS encryption and token-based authentication (via Timebase Pulse) are available on every historian connection, so edge-to-cloud data paths can be fully secured.
What is the recommended relationship between logging sessions and datasets?
Maintain a strict 1:1 relationship: one logging session writes to one dataset. While Timebase technically allows a session to target multiple historians (for redundancy), it still writes to a single dataset per session. Keeping the 1:1 rule makes future troubleshooting straightforward and makes backup or restore of historical files much easier to reason about.
When running in Docker, do I need separate containers for each protocol?
Only if you need different protocol types. If you are collecting from multiple sources using the same protocol and targeting a single dataset, one container is sufficient. If you need both MQTT and OPC UA collection, for example, spin up one container per protocol type.
We're adding new equipment regularly. Will we need to reconfigure collectors every time?
Not with wildcard subscriptions. Timebase collectors support wildcard patterns (across protocols: OPC UA, MQTT, and SparkplugB), that automatically discover and subscribe to new tags as equipment is added under the same namespace structure. A subscription to `Area 1.+.Cappers`, for example, captures every Capper in Area 1 today and any Capper added under that structure in the future. New equipment is historized the moment it appears, without any configuration change.
When using general subscriptions, how do I prevent unwanted tags (debug metrics, alarm chatter, etc) from being stored in the historian?
Use the Filter field, which accepts a .NET regular expression (RegEx) evaluated against each incoming tag name. Any tag whose name matches the pattern is excluded.
My MQTT broker publishes JSON. How do I choose between Simple, JSON (Simple), and JSON (Structured) payload types?
The Data Collector supports all three, just decide which to use based on how your payload is shaped. More details on payload identification in the Knowledge Base.
Our tag names in the source systems are not meaningful on their own. How does Timebase add context?
Timebase uses a feature called Fields, metadata key/value pairs attached to every tag at collection time. Fields can carry information like enterprise, site, area, machine, line, or any other classification that matters to your operations. Once stored alongside the time series data, Fields make it possible to filter, group, and query tags by operational context rather than relying on naming conventions or tribal knowledge.
Do we have to manually assign metadata to thousands of tags?
No. Timebase extracts metadata automatically from the structure of the data source itself using Topic Definition. For MQTT and SparkplugB, topic paths typically encode meaningful context (enterprise, site, line, equipment) and Topic Definition maps each level of that path to a semantic label. For OPC UA, the same principle applies to the server's folder-based address space. Once configured, every tag discovered under that subscription receives the correct metadata automatically, including tags from equipment added in the future. You define the mapping once; Timebase derives the context at scale.
Can metadata also come from inside the message payload itself, not just the topic structure?
Yes. Fields can be sourced from three places independently or in combination: hardcoded static values, values extracted from the topic/path structure, and values extracted from the message payload. For example, a device serial number or unit ID embedded in a JSON payload can be pulled out and stored as a Field on every tag from that device — without any post-processing step or external enrichment pipeline.
What if we want to add or correct metadata after data is already in the historian?
Fields can be updated at any time. From the Historian browser, you select the target tags and edit their Fields directly without interrupting data collection or touching the collector configuration. This means metadata corrections, re-classifications, or additions to existing tags do not require a re-ingestion or data migration.

Data historian

The data historian built by engineers, for engineers

Timebase is built by process and control engineers with decades of plant-floor experience and a deep respect for the people asked to do more with less. Every design choice reflects that reality, delivering the tools engineers actually need to do the job right.

1,000,000 Million Tags... and Growing

The Timebase Historian archive is tested continuously with more than 1,000,000 tags, sustaining not just large tag counts but high write speeds.

Zero Imposed Limits

Never be forced to make a decision about whether you can historize a tag again. Store what you want to store without worrying about tag licensing limits holding you back.

NoSQL Binary File System

If you need high resolution time series data performance, you can't use SQL. That's why we engineered our historian to use a file-based structure optimized for read and write.

Fast Logging Speeds

A Timebase Dataset is capable of 150,000 updates, or writes, per second. With speeds like that you can capture every point that matters without limitations.

Loss Less Compression

Every data point you store is a data point you keep. We use a purpose-built algorithm to ensure optimal storage without sacrificing data fidelity.
Estimate your storage needs

Simple to Manage

It's crucial that Operations can own and manage a historian. Timebase makes it easy for you to do just that. No database skills or advanced IT knowledge required.

Pick Your Platform

All Timebase components can run in a Windows environment or on Linux as docker containers. Rest assured, you will get the same great performance no matter your OS.

Redundant Servers and Dev Boxes

Run as many Timebase instances as you need. Data loggers will point to multiple servers ensuring independent data streams are writing values 24/7 to all your historians.

Start Using Timebase Today

Download

Data Historian FAQs

How much data can the Timebase Historian handle?
The historian supports up to 150,000 tag value updates per second. In AWS benchmark testing, a single instance running on an 8-core, 32GB machine handled 1 million tags across 10 datasets at 100,000 writes per second while consuming only 50% of available CPU. For organizations with large tag counts, datasets can be distributed across multiple instances, and the recommended maximum is 100,000 tags per dataset to maintain optimal performance. A storage estimator tool is available to help size deployments based on tag count, data type, and logging frequency before committing to infrastructure.
How does Timebase minimize storage consumption without losing data fidelity?
The historian uses delta storage, meaning it only records a new value when a tag's value actually changes from the previous one. If a sensor holds the same reading across 10 scan cycles, only one value is written rather than 10. This dramatically reduces storage requirements in real-world environments where the majority of tags are stable at any given moment. Crucially, original values are never modified or compressed in a way that alters them. The historian stores exact timestamps and values as received, satisfying the data integrity requirements common in regulated manufacturing environments.
How long can Timebase retain historical data, and how is data lifecycle managed?
Timebase is designed to retain data for extended periods, with many deployments targeting seven or more years of history. Retention is managed at the dataset level through configurable purge rules based on either age (number of days) or total size (gigabytes), giving organizations control over how long data is kept without manual file management. The underlying file structure stores data in hourly binary files, which makes archiving, moving, or removing older data straightforward. Old files can be archived or removed without disrupting ongoing data collection or requiring downtime.
How is historian data physically organized on disk, and what does that mean for data management?
The historian stores data in hourly binary files, with a new file created at the top of every hour. Each file contains all timestamps, values, and quality information recorded during that hour for the tags in that dataset. Numeric and Boolean values are stored in .data files, while string and object values are stored in separate .object files. If a dataset exceeds 20,000 tags, the hourly block is automatically split across multiple files to maintain performance. This segmented structure means that any time-bound operation, whether a query, an archive, or a deletion of old data, touches only the relevant hourly files rather than a monolithic database, which keeps operations fast and surgical.The tag list, including all tag names, descriptions, data types, units of measure, and metadata Fields, lives separately in a tag.config file. This file is the index that connects tag identities to the values stored in the hourly data files, and it must always be included in any backup or recovery operation alongside the data files themselves. Without it, the historical values cannot be interpreted. The practical benefit of this architecture is that backup, restore, and archiving are straightforward file copy operations with no database tooling required, and individual hourly files can be moved or archived independently without affecting ongoing data collection.
How straightforward is it to back up and recover historian data?
The file-based architecture makes backup and recovery simple compared to traditional database systems. A complete backup requires only the hourly .data and .object history files along with the tag.config file, which maps tag identities to the stored data. There are no proprietary backup utilities or database export processes required. Files can be copied to any external location, network share, or cloud storage using standard IT procedures. For Docker deployments, Docker Volumes are the recommended approach for persistence and backup. In a recovery scenario, restoring the files restores the complete historical record.
Can Timebase integrate with our existing analytics tools and applications?
Yes. The historian exposes a REST API that covers the full range of operations: reading tag data for single or multiple tags, writing data, managing datasets, and querying tag metadata including Fields. Time range queries support ISO timestamps, UNIX timestamps, and relative time expressions such as "-2h" for two hours ago, making it straightforward to embed historian queries in dashboards, reporting tools, or custom applications. Timebase Historian supports the i3X API (pioneered by CESMII), and offers a WebSocket interface is also available for applications that need to subscribe to live tag updates as they arrive, rather than polling on a schedule.
Does Timebase support AI and language model integrations?
Yes. The historian includes a built-in MCP (Model Context Protocol) server with tools already built and ready for use by the agent of your choosing. Through the MCP interface, AI tools can access tag lists, tag metadata, and time series data directly, enabling natural language queries against live and historical process data without custom integration work.
How does Timebase handle high availability at the historian level?
Timebase supports active redundancy by allowing a single logging session to write identical data to two independent historian instances simultaneously, in real time. Both historians operate concurrently, so if one becomes unavailable due to hardware failure, maintenance, or a network issue, the other continues receiving data without interruption. Store and forward in the collector ensures that the historian that went offline is fully reconciled and brought current once it comes back online, with no gaps in either historian's record. This provides a resilient data collection architecture without requiring external replication software or complex failover configuration.

TIMEBASE Explorer trending

Get serious about your diagnostics

Making your data work for you is all about having great trending tools at the ready for your engineers and operators. Explorer trending delivers in a major way. Run batch comparisons, do detailed trend over trend analysis, and quickly convert pens into raw data tables... and yes, you can export them to CSV.

More than just trend lines, Explorer provides unique State visualization and high-level context views of key variables.

Quickly pivot between trends and data tables, with perfect time stamp normalization across various data resolutions.

Overlay multiple batches and compare key data points with perfect alignment.

When you convert various batches or period comparisons to data tables, the timestamps sync to the event start.

State Tag Visualization

Explorer includes a dedicated draw style for condition-based tags where the value represents a mode or state rather than a numeric magnitude. Instead of rendering as a stair-step line that can be difficult to read at a glance, State display renders clean, color-coded blocks that span each period the tag held a given value. When the state changes, the block changes color and label instantly. This makes it easy to visualize equipment modes, recipe states, or alarm conditions alongside continuous process data in the same trend view, without the clutter of a traditional line chart.

Batch and Run Comparisons with Frames

Explorer's Frame system is purpose-built for batch and run comparisons. Users can define up to three Frames, each pinned to a different batch or production run, and Explorer automatically left-edge aligns the start of each Frame across all Trend Bands. This means two or three runs of different durations are displayed side by side from their respective start points, making deviations in process behavior immediately visible without any manual time-shifting or external tooling. Frames can be precisely set to match known batch start and end times, and because up to six tags can be plotted per Trend Band, multiple process variables from each run can be compared simultaneously in a single view.

Period-over-Period Comparison with Frames

Explorer's Frame system lets users define up to three distinct time periods simultaneously and overlay them for direct comparison. Frames can be dragged, resized, and renamed, and when multiple Frames are active, all Trend Bands automatically left-edge align the start of each period so comparisons are visually immediate and require no manual adjustment. This makes it straightforward to compare this week's production run against last week's, or to isolate a normal operating window next to an anomalous one, without leaving the tool or exporting data.

Relative Time and Live Mode

Frames can be configured with relative time expressions (such as -1h for one hour ago or -1d for one day ago) rather than fixed timestamps. When Live Mode is enabled, relative Frames continuously advance with the clock, keeping the view anchored to the present. This means an operations team can build a standard view that always shows the current shift versus the prior shift, and that view stays current every time it is opened without any manual date adjustments.

Find Tags Using Metadata

Explorer can switch from a visual chart to a structured data table that aggregates all plotted tags into a single wide format, normalized by timestamp. Where a tag has no value at a given timestamp, the prior value is carried forward to produce a complete, point-in-time accurate row. This view is well suited for sharing findings, feeding offline analytics tools, or validating data quality, and the entire result set can be exported as a CSV with a single click.

Data Table View with CSV Export

Explorer can switch from a visual chart to a structured data table that aggregates all plotted tags into a single wide format, normalized by timestamp. Where a tag has no value at a given timestamp, the prior value is carried forward to produce a complete, point-in-time accurate row. This view is well suited for sharing findings, feeding offline analytics tools, or validating data quality, and the entire result set can be exported as a CSV with a single click.

Data Access

It's your data, do with it as you please

The Historian ensures your raw and original values are stored for as long as you desire. But what good is stored data if it's locked away behind a proprietary database with no access? No worries, Timebase makes it easy to use your data and make it work for you.

REST API

Query data as you need it using the well documented REST API. Search for tags. Assign metadata. Call for raw timestamp, value, and quality data points.

MCP Server

The commercially available MCP Server provides you the ability to plug in the LLM or AI agent of your choosing. Test it for free with the current beta release in version 1.2.

WebSocket

Need to subscribe to your data on change? Timebase Historian’s WebSocket connection delivers event-driven updates the moment values change. This enables DataOps pipelines to react immediately, triggering validations or downstream publishing without polling.

i3X API

The i3X API (Industrial Information Interoperability eXchange) is an open, vendor-agnostic REST API specification designed to standardize how software applications access contextualized manufacturing data. Developed by CESMII, it aims to eliminate "API chaos" and vendor lock-in across industrial environments.

The team at Flow Software has a pair of AI Gateway solutions that couple MCP servers with the prebuilt tools you need to be successful right out of the box. Our team has worked hard to provide short context windows that make it possible for you to connect any MCP compliant agent to your data. Both Timebase and Flow Software's Infohub can be upgraded to include AI Gateway.

Use AI To Better Understand Your Historian

The team at Flow Software has a pair of AI Gateway solutions that couple MCP servers with the prebuilt tools you need to be successful right out of the box. Our team has worked hard to provide short context windows that make it possible for you to connect any MCP compliant agent to your data. Both Timebase and Flow Software's Infohub can be upgraded to include AI Gateway.