A few years ago, when we first started introducing TDengine to industrial customers, we started hearing a pattern.
More teams were looking for alternatives to PI System.
The reasons varied: cost, performance, openness, cloud strategy, integration flexibility, or simply wanting more control over operational data. But the direction was clear. Many industrial companies were starting to ask what a modern historian should look like beyond the traditional PI environment.
At that time, some customers took a very practical first step. They tried to combine a time-series database with Grafana and use that as a lightweight PI replacement. In some cases, that time-series database was TDengine. And honestly, I understood why.
If the problem is only storing high-volume time-series data and visualizing trends, the idea makes sense. A modern TSDB can ingest data efficiently, query it quickly, compress it well, and expose it through open interfaces. Grafana can provide dashboards and trends. For a simple monitoring use case, that can be attractive.
But after more customer discussions and real evaluations, one thing became very clear:
A time-series database plus a generic visualization tool is not the same thing as PI System. And it is not enough to replace a serious industrial historian.
PI is more than time-series storage
PI became the standard for a reason.
It was not only because it stored process values. Many systems can store timestamped data. PI became deeply embedded because it matched how industrial teams work. Engineers, operators, maintenance teams, and process experts do not think only in terms of rows, timestamps, and values. They think in terms of assets.
Plants. Areas. Lines. Units. Equipment. Instruments. Batches. Events. Alarms. Operating modes. Process relationships. That context is what makes historian data useful.
A tag by itself is rarely enough. An engineer usually needs to know:
- What equipment does this tag belong to?
- Where is it in the plant?
- What unit is it measured in?
- What operating condition was the asset in?
- Was there an alarm or event at that time?
- Is this behavior normal for this asset, batch, recipe, or site?
- How does this compare to similar equipment?
- What changed before the issue started?
That is where a basic TSDB + dashboard approach starts to fall short. It can store the data. It can visualize the data. But it does not automatically make the data understandable in the way PI users expect.
The missing layer is context
For many PI users, the real value is not just PI Data Archive. It is the ecosystem around it: Asset Framework, Event Frames, calculations, displays, reports, DataLink workflows, PI Vision, integrations, and years of operational knowledge built into the environment.
That is why replacing PI is not just a database decision. It is an operational workflow decision.
A TSDB can be a strong foundation, but on its own it does not provide:
- Asset-centric organization
- Equipment hierarchy and metadata
- PI AF-style modeling concepts
- Event Frame-style time-window context
- Alarm and event relationships
- Engineering-friendly data discovery
- P&ID-style navigation or operational views
- Operations-focused dashboards and panels
- Advanced analytics tied to assets and events
- AI grounded in historian data and context
These are not “nice to have” features for serious historian users. They are often the reason the historian is useful in daily operations.
Grafana is useful, but it is not a historian workspace
Grafana is a great visualization tool. Many industrial teams use it successfully, including with TDengine. But Grafana is a generic dashboarding layer. It is not designed to be a full PI-equivalent historian workspace.
That distinction matters. A dashboard can show a trend. But a historian workspace needs to help engineers navigate from an asset to its measurements, from a measurement to related events, from an event to the surrounding process history, and from one site or asset to comparable peers. It needs to support how people actually investigate problems.
For example:
- A packaging line has microstops.
- A fill/finish line has higher reject rate.
- A cleanroom has pressure excursions.
- A pump is behaving differently than similar pumps.
- A batch quality issue appears after a certain process phase.
- A simple dashboard may show the signal.
- A historian workspace should help explain the context around the signal.
That is a much higher bar.
What we learned from customers
This is one of the biggest lessons we learned while talking to industrial customers over the last few years.
At first, many conversations started around the database layer.
- Can TDengine ingest fast enough?
- Can it compress better?
- Can it query faster?
- Can it scale to large tag counts?
- Can it connect with Grafana?
- Can it expose SQL or APIs?
Those questions still matter. A modern historian absolutely needs a strong time-series foundation. But as the conversations became more serious, the questions changed.
- Can it organize data around assets?
- Can engineers find the data naturally?
- Can it model events and alarms?
- Can it support operational dashboards?
- Can it help with root-cause analysis?
- Can it integrate with existing systems?
- Can it support AI workflows?
- Can it give users a practical alternative to PI, not just a faster database underneath?
That is the real historian conversation.
A modern PI alternative needs both layers
A real PI alternative needs two things at the same time.
First, it needs a modern time-series data foundation.
That means:
- High ingestion performance
- Fast queries
- Efficient compression
- Long-term retention
- Open SQL/API access
- Edge, on-premises, and cloud deployment options
- Reliable integration with industrial data sources
But that is only the lower layer. On top of that, it also needs the historian experience:
- Asset context
- Equipment hierarchy
- Event and alarm workflows
- Operational dashboards
- Engineering-friendly navigation
- Advanced analytics
- Data sharing and integration
- AI-assisted investigation
Without the first layer, the system cannot scale. Without the second layer, it is not a real historian replacement.
That is why I do not believe “TSDB + Grafana” should be positioned as a full PI equivalent. It may solve part of the problem. It may be good for lightweight monitoring, dashboards, or specific new use cases. But for customers who rely on PI as an operational historian, the bar is much higher.
How our thinking evolved at TDengine
TDengine started with a high-performance time-series database foundation. That foundation is still important. Industrial data volumes are growing, and customers need performance, scalability, compression, and openness.
But customer conversations made something very clear:
A database alone is not enough.
Industrial teams do not only want to store more data. They want to understand it faster. They want to organize it around assets. They want to connect it to events, alarms, dashboards, analytics, reports, and engineering workflows.
And increasingly, they want AI to help them investigate issues, summarize findings, compare assets, identify outliers, and recommend what to check next. That requires more than a TSDB. It requires a historian.
That is why TDengine Historian has been moving beyond the database layer toward asset context, operational dashboards, analysis workflows, event and alarm context, integrations, and AI-assisted investigation. Not because the TSDB layer matters less. Because the TSDB layer is only one part of what PI users actually need.
AI raises the bar even further
AI makes this distinction even more important.
A generic chatbot sitting next to a dashboard is not enough. For AI to be useful in industrial operations, it needs to be grounded in historian data and operational context. It needs access to live values, historical trends, asset relationships, metadata, alarms, events, and engineering workflows. Otherwise, it may generate a fluent answer, but not a useful one.
The future historian should help answer questions like:
- Which asset is behaving abnormally?
- What changed before the issue started?
- Which tags should we compare?
- Did related alarms or events occur?
- Is this site different from sister sites?
- What should engineering investigate first?
That is where AI-powered historians become interesting. Not as a replacement for engineers. As a way to help engineers move faster from investigation to action.
The real question
PI became the standard because it solved a real industrial problem. It taught the market that historian data is not just time-series storage. It is operational context.
So the question is not whether PI has been successful. It has.
The question is what industrial data infrastructure should look like for the next 10 years.
My view is simple:
The future historian needs to be both a high-performance time-series data layer and an asset-aware operational workspace.
A TSDB can store the data.
Grafana can visualize the data.
But a real industrial historian has to make the data meaningful, usable, and actionable.
That is the difference between building dashboards and replacing PI.
