Jeff Tao

Data portability isn't something you can retrofit. If the platform wasn't designed from day one with open formats, standard interfaces, and the assumption that data will need to leave, it will never be truly portable. The reason is simple: the cost of retrofitting portability grows with the data volume. Every year of proprietary storage makes the retrofit harder and more expensive. At some point, it becomes economically impossible. Portability is an architectural decision made in year zero. After that, the window closes.

TDengine and PI. Two platforms can do the same thing on paper and be built for completely different eras. A historian built in 1990 and a historian designed with AI in mind both "manage time-series data." Same category label. Completely different job description. The category name hasn't changed. What's expected of the platform has. Displaying trend lines on a screen was enough when the only consumer was a human operator. When the consumer includes AI agents, a recommendation engine, and a natural language interface, the requirements are different all the way down.

An industrial software stack needs to run at two different speeds. The top layer is dashboards, workflows, interfaces. Those should change fast. Whenever the need shifts. If something stops working, swap it. The bottom layer, the data foundation, needs stability. Consistent schemas. Predictable APIs. Change here is slow by design, not by neglect. Most organizations today run both layers at the same speed: slow. Because they were built as one thing and the coupling runs all the way down.

The natural instinct is to build the data foundation first and figure out AI later. Get the basics right, then add intelligence. I think that instinct is wrong and expensive. If your data model isn't built for machine readability from the start, by the time you're ready for AI agents the foundation needs a rebuild. Foundation rebuilds in industrial systems are measured in years. Build for the consumers you'll have in three years, not the ones you have today. Those are two different audiences.

Traditional systems accumulate hidden costs including proprietary infrastructure, fragmented tooling, and the ongoing expense of specialized personnel needed to extract value from the data. First: proprietary infrastructure. Once you're locked into a vendor's stack, every integration, every upgrade, every new use case runs through their pricing model. Second: fragmented tooling. Five different systems. Five different data formats. Five different ways to answer the same question. The cost isn't the license fees. It's the friction.

Four shared drives + three senior colleagues + half a day. That is what it can cost an engineer to find a post-mortem report from three years ago. We put the same report into a knowledge base attached to the equipment instead. Upload the case to the fan, and it links to other fans of the same model, to similar equipment in the same workshop, and to the upstream points involved in the same fault. A folder on a drive is storage. Attached to the equipment, the same document becomes something people actually find.

Most alert tuning happens far from the equipment. Someone who has never run the line sits down with a threshold and a spreadsheet. Alert quality is not a configuration problem. It depends on how close the rule author stands to the process. A shift leader knows which 0.05 MPa drift is noise and which one precedes a real event, and that knowledge beats any default value. Give the rule back to the person who owns the process and both failure modes drop. Missed alarms and false alarms.

A conversational assistant will tell you to check the bearing. Then you check the bearing. You write the SQL, build the trend chart, set the alert rule, and file the report. Every operational step that follows the answer is still manual, because the AI was never given a way to call the system it is describing. An answer that ends in homework is not automation.

Over the past few years, a lot of industrial software shipped a chat window and called it AI. Most of those deployments go quiet within a month. Not because the model was bad, but because three things were never connected. The data had no business meaning. The AI could not operate any system tool. And nothing proved why its answer should be trusted. Adding a chat box to a platform that was built without a place for AI leaves the AI sitting on the surface. It writes text. It never reaches the process. #AIAgent

35 million rows a day. 2 billion rows in 7 months. Just 2% of one CPU core. These aren't benchmark numbers. They're real production results from our customer, DJIN EMS. DJIN EMS builds intelligent energy management systems for battery storage and the grid edge. They chose TDengine TSDB to power their on-site historian, running alongside real-time control and local AI on the same industrial appliance. The results are impressive: 1: 35 million rows ingested daily across three operating sites 2: 870 million rows stored in just 21 GiB at their busiest site 3: 11× compression for 50 Hz control data 4: ~20 ms to query a full day's trend 5: Only 2% of one CPU core consumed by TDengine What excites me most isn't just the performance. It's what this efficiency makes possible: running high-resolution data collection, real-time control, and local AI together on a single edge device, without depending on the cloud. This is exactly why we built TDengine: to make industrial data infrastructure dramatically more efficient, affordable, and accessible. A big thank you to Nick Hughes and the DJIN EMS team for sharing their experience and real-world results! Read the full case study: tdengine.com/how-djin-ems-ca… #TDengine #TimeSeriesDatabase #IndustrialAI #EdgeComputing

When ChatGPT emerged, I knew immediately: this wave is different. Bigger than the internet. Bigger than mobile. But the deeper I studied AI, the clearer one thing became. Without solving the industrial data foundation, LLMs will remain an impressive technology demonstration. Not a practical industrial solution. That conviction is what drove everything we built over the last two years. #IndustrialAI

The moment trying a new analytics tool requires a conversation with your existing vendor about whether they support it, you've already lost. You're not evaluating technology. You're negotiating with an incumbent who has no incentive to make the new thing work. Your innovation velocity is now capped by someone else's product roadmap. In an open architecture, you try the new tool and see if it works. In a closed one, you ask permission first. Those are fundamentally different operating models. #Innovation

An anomaly detection model running on yesterday's data export is generating yesterday's insights. In industrial operations, that's not intelligence. That's a post-mortem. Continuous, in-situ analytics means the model sees what's happening right now. The anomaly gets flagged while the equipment is still running, not during the morning review. The difference between batch and real-time isn't about speed. It's about whether the insight arrives in time to act on it. #OperationalIntelligence

For a long time, storing a document meant storing its text. Search it, retrieve it, done. A knowledge graph stores something different. It pulls out the entities, then writes down the relationships between them: causes, depends on, applies to, limited by, leads to. Two things change once that is in place. A conclusion can be traced back to its source and the constraints around it. And knowledge learned on one asset carries over to the next similar one instead of being relearned. #KnowledgeGraph

I have always considered myself a programmer. Not a title. Not a role. A way of thinking. A way of turning ideas into things that solve real problems. The part I have always enjoyed most is building from scratch. First lines of code. Designing architectures. Solving hard technical problems. Seeing real people use what you built. Everything changed with AI. But that part did not.

"Outlet temperature of Furnace #3 is 620°C." An LLM sees a number. It does not know which production line Furnace #3 belongs to. What product is running. What the normal range is. Whether 620 means everything is fine, or something is about to fail. To AI, this is just a data point. To a plant engineer, it might be the most important number in the building. That gap is the whole problem. #IndustrialAI

Strict version alignment between components sounds like a technical requirement. In a closed ecosystem, it's also a control mechanism. When you can't upgrade one piece without upgrading everything else, and the upgrade path runs through the vendor's timeline and pricing, you've lost the ability to make independent infrastructure decisions. Your roadmap is now a subset of their release schedule. Loose coupling isn't just good architecture. It's good negotiating position. #SystemArchitecture

Data duplication isn't just a storage cost. Every time you copy industrial data to an external AI tool, you create a governance problem. Which copy is authoritative? Who has access? Was the data anonymized before it left? When analytics run inside the data platform, those questions go away. One copy. One governance boundary. One set of access controls. Keeping compute near data isn't just a performance argument. It's a compliance argument. #DataGovernance

Raw industrial data without context is like a warehouse full of unlabeled parts. You might know the dimensions. You don't know which machine they go in, which process they belong to, or why they were pulled. Contextualization is the labeling step. It maps each signal to an asset, each asset to a hierarchy, each measurement to an operating condition. With that in place, an AI agent can start reasoning about what's going on. Without it, it's staring at a pile of numbers. #IndustrialAI

We organize industrial data assets in trees. But the real world is a network. A pump feeds a reactor. A motor drives a pump. An analyzer monitors a process. How do we model relationships like these? In the latest TDengine IDMP, we’ve introduced Related Elements. Explorer still uses the familiar tree structure to organize and navigate plants, areas, production lines, equipment, and other elements. But now, you can also visualize the relationships between elements as a graph. Creating a relationship is simple: just drag and drop. You can define the relationship type and direction, and explore the graph by relationship type, direction, and display depth. The tree and the graph complement each other — one shows the hierarchy, while the other reveals how assets are actually connected. This becomes even more important in the AI era. Time-series data tells AI what happened. The asset hierarchy provides context about where it happened. Relationships add another critical layer of context: what feeds what, what controls what, what depends on what, and what may affect what. With this richer context, AI can better understand industrial data, trace dependencies, investigate anomalies, discover correlations, and ultimately extract more value from the data. The tree tells you where an asset belongs. The graph tells you how the plant works. With Related Elements feature, TDengine IDMP gives you both.