DEV Community: Timecho

Query Apache TsFile Directly with DuckDB

Timecho — Sun, 20 Sep 2026 12:17:38 +0000

Industrial IoT systems continuously generate massive amounts of time-series data from sensors, devices, and machines. Efficiently storing and analyzing this data is critical for many IoT applications.

Apache TsFile is an open-source time-series file format developed as part of the Apache IoTDB ecosystem. It serves as the underlying storage format for IoTDB and is designed to efficiently store large volumes of industrial IoT time-series data with optimized encoding, compression, and time-series access capabilities.

However, after data is stored in TsFile, users may want to explore and analyze it with different tools beyond the original database environment.
This is where the DuckDB-TsFile Extension comes in.

Bringing TsFile into DuckDB Analytics

DuckDB is an in-process analytical database that provides powerful SQL capabilities for data exploration and analysis.

Instead of converting TsFile data into another format first, the DuckDB-TsFile Extension connects Apache TsFile with DuckDB, allowing users to query TsFile table-model files directly through SQL.

The workflow becomes simple:
IoT Data → Apache TsFile → DuckDB → SQL Analytics

Getting Started

Install and load the extension:

INSTALL tsfile FROM community;
LOAD tsfile;

Then query a TsFile using read_tsfile():

SELECT time, device_id, temperature
FROM read_tsfile('/data/measurements.tsfile', 'sensors')
WHERE time BETWEEN 1700000000000 AND 1700003600000;

With this extension, TsFile data can be explored using familiar SQL operations such as filtering, aggregation, and analysis.

Why DuckDB + TsFile?

TsFile and DuckDB focus on different parts of the data workflow:

Apache TsFile focuses on efficient storage of industrial time-series data.
DuckDB focuses on lightweight analytical SQL processing.

By connecting them together, developers can use TsFile as a time-series data source while taking advantage of DuckDB's analytical capabilities.
This provides a simpler workflow for scenarios such as:

Exploring historical sensor data
Performing time-range analysis
Preparing datasets for further analytics or machine learning workflows

Current Capabilities

The DuckDB-TsFile Extension currently supports querying Apache TsFile table-model files through DuckDB.

Key capabilities include:

Reading TsFile data directly with read_tsfile()
Querying TsFile data using DuckDB SQL
Projection pushdown
Time-predicate pushdown
TAG predicate pushdown
Exporting query results to TsFile format using COPY ... TO ... (FORMAT TSFILE)

The initial release focuses on one local file and one table per scan. Features such as tree-model file support, multi-file scans, automatic table discovery, parallel scans, and FIELD predicate pushdown are not yet implemented.

Conclusion

The combination of Apache TsFile and DuckDB creates a bridge between time-series optimized storage and modern SQL analytics.

With the DuckDB-TsFile Extension, developers can access TsFile data directly through DuckDB SQL, making industrial IoT time-series analysis more flexible and accessible.

Explore the extension: https://duckdb.org/community_extensions/extensions/tsfile

Handling Out-of-Order Data in IoT Time-Series Workloads

Timecho — Wed, 16 Sep 2026 09:58:52 +0000

In a connected system, the order in which data arrives is not always the order in which events happened.

A gateway may buffer readings while a network link is unavailable. A device may reconnect and upload several minutes of measurements. A message can take a longer route than the one sent after it. When the data reaches a backend, a later event may appear first and an earlier event may arrive afterward.

Out-of-order data means a record arrives whose event timestamp is earlier than events the system has already received.

This is normal in IoT. The challenge is making sure the data system treats it as an expected operating condition rather than as an exceptional error.

Event time and arrival time are different signals

Consider three measurements from the same pump:

The event timeline is A → B → C. The backend receives them as A → C → B.

If a pipeline assumes arrival order equals event order, it can temporarily show the wrong sequence. A windowed calculation may omit a delayed point, a chart may display a misleading transition, and an investigation may confuse a network delay with a change in equipment behavior.

The two timestamps answer different questions:

Event time: When did the measurement occur at the device or source system?
Arrival time: When did the platform receive or process the measurement?

For equipment monitoring and historical analysis, event time is usually the timeline that describes the physical process. Arrival time remains useful for diagnosing the data path, measuring delay, and understanding freshness.

Why out-of-order data is common in industrial IoT

Industrial systems rarely have one perfectly synchronized path from sensor to database. Several mechanisms can change arrival order:

Edge buffering: A gateway stores readings locally and forwards them in batches.
Intermittent connectivity: A remote device reconnects after a temporary outage.
Different network paths: Messages travel through routes with different latency.
Protocol or adapter behavior: An integration component queues, retries, or batches data.
Clock and processing differences: Devices and collectors timestamp or process readings at different points in the pipeline.

None of these automatically means the measurement is invalid. It means the ingestion path and the event timeline have to be modeled separately.

What a time-series system needs to handle

A useful design starts with a few practical questions:

Which timestamp represents the observation that engineers want to analyze?
Can the ingestion path accept a measurement whose event time is earlier than the latest arrival?
How are delayed points reflected in time-range queries and aggregations?
Can teams distinguish a late measurement from a bad timestamp or a duplicated record?
How much delay is normal for each device, gateway, or source system?

These questions connect data modeling, ingestion, and operations. Treating every late record as an error can discard useful history. Treating every timestamp as trustworthy without checking source behavior can create a different class of problem.

How Apache IoTDB fits this workload

Apache IoTDB is an Apache open-source, IoT-native time-series database. Its data model is designed around devices, measurements, and time, and it supports high-speed ingestion of out-of-order and multi-frequency data.

That positioning is relevant when the physical process does not produce a neat, evenly spaced stream. A device hierarchy can keep measurements associated with the right asset and subsystem. Ingestion can account for readings that arrive late or at different frequencies. Time-aware queries can then work against the observation timeline rather than forcing teams to redesign the data around network arrival order.

The benefit is not that every data-quality issue disappears. Source timestamps can still be wrong, clocks can drift, and duplicate or corrupted records still need operational policies. A time-series database provides a better foundation for handling those realities because event time remains a first-class part of the workload.

A practical ingestion pattern

One workable pattern is to keep the path explicit:

Collect: capture the measurement and the source event timestamp at the edge or device boundary.
Transport: send readings through the gateway or message path, allowing for retries and temporary buffering.
Ingest: write the measurement to the time-series database without replacing its event timestamp with the arrival time.
Analyze: use event-time windows for trends, comparisons, and investigations; use arrival-time information to monitor pipeline health.
Review: define how unusually late, duplicated, or implausible timestamps are flagged for follow-up.

This pattern keeps two concerns visible: what happened in the physical system, and how the data moved through the platform.

Conclusion

Out-of-order data is not an edge case in IoT. It is a consequence of buffering, unreliable connectivity, retries, and distributed collection. The important distinction is between when an event happened and when the platform received it.

Apache IoTDB provides an open-source time-series foundation for workloads where measurements may arrive late or at different frequencies. With a clear event-time model and a separate view of pipeline arrival, teams can keep the physical timeline intact while still investigating data freshness and delivery behavior.

To try Apache IoTDB or learn more about the project, visit the Apache IoTDB GitHub repository.

Apache IoTDB + Timer: A Data and AI Architecture for Nuclear Power Maintenance

Timecho — Mon, 14 Sep 2026 09:48:32 +0000

Nuclear-power maintenance is a data problem with boundaries that matter. Equipment runs for long periods, measurements arrive around the clock, and a maintenance decision may depend on a small change in vibration, pressure, temperature, or an electrical signal. That change only becomes meaningful when it is tied to the right asset, operating mode, timestamp, and historical baseline.

The analytics layer therefore has two jobs: preserve the evidence behind an observation and help engineers find patterns early.

Why nuclear operations need a dedicated time-series layer

Nuclear-power facilities contain complex equipment and tightly connected subsystems. Sensors can produce vibration, temperature, pressure, flow, level, current, voltage, and other measurements. Those signals do not necessarily share the same sampling frequency. Some are high-frequency condition-monitoring streams; others are slower operational or environmental measurements.

The resulting workload has several characteristics:

Many measurement points: equipment and auxiliary systems produce data through numerous sensors.
Different temporal resolutions: a vibration signal and a temperature signal may need different collection intervals.
Long retention horizons: maintenance and reliability analysis often depend on comparing current conditions with historical behavior.
Operational context: a value should be interpreted alongside the asset, subsystem, operating state, and related signals.
Decision traceability: an alert must point back to the measurement, asset, time window, and operating context that produced it.

These requirements make time, measurement identity, asset hierarchy, and operating context part of the data model. They are not optional metadata added after the fact.

The role of a time-series database

A time-series database provides the data layer for measurements that evolve over time. In an industrial setting, that layer should make it practical to ingest signals, organize them by device and measurement point, retain history, and ask time-aware questions.

Apache IoTDB is an Apache open-source IoT-native time-series database. It supports hierarchical measurement-point management, high-speed ingestion for out-of-order and multi-frequency data, unified management of historical and real-time data, timestamp alignment during queries, and time-series computation functions.

These capabilities map directly to the workload above: hierarchy connects a measurement to an asset and subsystem; out-of-order and multi-frequency ingestion reflects how plant data actually arrives; unified historical and real-time management supports both live monitoring and long investigations; and timestamp-aware queries make cross-sensor comparison more reliable.

Where the IoTDB + Timer architecture fits

An architecture that pairs Apache IoTDB with Timer separates two related responsibilities. IoTDB is the time-series data foundation: it organizes equipment measurements, preserves timestamps and operating context, and provides a path for querying historical windows. Timer is a time-series foundation-model product from Timecho, that can analyze temporal patterns for tasks such as anomaly detection, trend forecasting, and equipment-health assessment.

Why add a model when a database can already answer historical queries? Queries and thresholds are useful for known conditions, but they become less effective when several signals interact, labels are scarce, operating modes change, or degradation develops slowly. A time-series foundation model can add pattern recognition across related series and longer windows; it complements rules and statistics rather than replacing them.

In a nuclear plant, this combination belongs in a monitoring and analytics layer outside the plant's safety-related protection and control systems. It can consume approved, one-way or mediated data feeds from historians, condition-monitoring systems, or other plant data services. It should not issue commands to safety-class protection systems or DCS controls; keeping this layer separate supports a defense-in-depth approach. Data classification, access control, change management, audit trails, and the applicable nuclear quality-assurance framework (for example, NQA-1-based controls in some jurisdictions) must be determined by the licensee for the specific function. AI output remains advisory unless the relevant use is separately qualified and approved.

From monitoring to prediction to assessment

The value of the architecture is easiest to see as a progression: first identify a change, then estimate where it is heading, and finally combine evidence into a current health view. Each step uses the same time-series context while adding a different kind of support for maintenance work.

1. Condition monitoring

Condition monitoring compares equipment signals over time to identify changes that deserve attention. Vibration, temperature, pressure, and electrical measurements can be reviewed together rather than as isolated charts. IoTDB keeps the signals associated with the correct asset and observation period; Timer can help surface multivariate patterns for engineering review.

2. Trend forecasting

Some maintenance questions are about direction rather than a single threshold. Is a temperature trend drifting? Is pressure behavior changing gradually? Timer can estimate likely future patterns when it has suitable historical context, while IoTDB makes the relevant history available and traceable.

3. Health-state assessment

A health assessment combines multiple signals and operating context to describe a current condition. In practice, this could support reviews of rotating equipment, auxiliary systems, or cooling-related assets. The output becomes a structured input to an engineer's assessment.

What teams can evaluate first

Start with one maintenance workflow outside these safety functions, then map its asset hierarchy, signal cadence, retention needs, operating modes, and review criteria. Test whether Apache IoTDB can provide the required ingestion, history, and time-aligned queries. Then evaluate Timer or another suitable model against representative historical data, with clear thresholds for escalation and a documented engineer review step.

The practical goal is not to replace engineering judgment. It is to make the evidence behind that judgment easier to collect, compare, and use while keeping safety functions, quality controls, and decision authority where they belong.

Conclusion

Nuclear-power operations need a data foundation that respects continuity, equipment context, and long-term history. Apache IoTDB can provide that foundation for a monitoring and analytics layer outside the plant's safety-related protection and control systems, while Timer can add model-assisted pattern analysis, forecasting, and health-state support. Together, they offer a focused path from high-frequency plant measurements to more informed maintenance work without blurring the boundary between analytics and safety control.

Model IoT Data Before You Store It: Device, Measurement, Timestamp

Timecho — Fri, 11 Sep 2026 02:50:27 +0000

When an IoT payload lands in a database, it is tempting to focus on the value first.

72.4

But a value alone is not yet useful time-series data. Before you choose a schema, connector, or query pattern, you need to know:

what produced the value;
what the value measures; and
when that observation happened.

This article uses Apache IoTDB terminology to make that model concrete. It is intentionally a modeling guide, not a syntax tutorial: check the current release documentation before writing DDL or queries.

The three fields of context

1. Device: the real-world collection object

In Apache IoTDB, a device can be a physical device, a measurement apparatus, or a collection of sensors. In a connected system, that might be a robotic arm, wind turbine, vehicle, meter, or monitoring host.

The device answers: Where did this reading come from?

That answer should be stable enough to support investigation. If an engineer sees a signal change, they should be able to connect it to a recognizable asset—not just a generic message source.

2. Timeseries: the quantity being observed

A timeseries is a measured physical quantity that generates data points over time. Temperature, voltage, current, speed, vibration, humidity, and fuel level are all examples.

The timeseries answers: What does this value mean?

One device can produce many timeseries. That is why device and measurement should not be collapsed into the same concept. A motor’s temperature and vibration signals may share an asset identity while differing in unit, frequency, data type, and the questions they can answer.

3. Data point: the value at a specific time

A data point consists of a timestamp and a value. The timestamp indicates when the data was generated; the value is the result recorded for that timeseries at that time.

The data point answers: What was observed, and when?

Here is a conceptual record:

device:      pump-42
measurement: outlet_pressure
timestamp:   2026-09-10T09:15:00Z
value:       72.4

This is a modeling sketch, not an Apache IoTDB insert statement. The purpose is to show the context you want to preserve.

Use a modeling worksheet before defining a schema

For each representative signal, complete this small worksheet:

Question	Example answer
What is the device?	`pump-42`
What is the measurement?	`outlet_pressure`
What does the value represent?	A pressure reading in the approved unit
Which timestamp matters?
How often is it collected?
What will someone ask about it?

This worksheet exposes gaps early. If the team cannot state the unit, source, or time meaning of a signal, it will be difficult to make reliable comparisons later.

Do not ignore collection frequency

Apache IoTDB defines collection frequency as the number of times a physical quantity generates data within a period. It matters because different signals produce different amounts of temporal detail.

A vibration signal collected frequently and a temperature signal collected once each minute are both time series, but they should not be interpreted in the same way. Frequency affects the density of observations, the questions a signal can support, and the engineering requirements that follow. Record the expected frequency as part of the signal’s context rather than treating it as an afterthought.

Separate observation time from arrival time

One implementation detail deserves an explicit question: does the timestamp represent when the source observed the condition, or when another component received the message? Those moments can differ when devices buffer data, gateways reconnect, or networks delay delivery.

The appropriate handling depends on the source system and the workload. The practical rule is to name the time semantics before writing the schema. If the source cannot provide a trustworthy observation time, record that limitation instead of silently treating arrival time as the same thing. This makes later investigations more honest and helps prevent misleading comparisons across signals.

Device and timeseries stay central in both IoTDB models

Apache IoTDB supports a tree model and a table model. Their organization and syntax differ, but both manage devices and timeseries. That means the vocabulary in this article remains useful before you make a model-specific decision.

Start with the data and the questions you need to answer. Then use the current Apache IoTDB documentation to choose the appropriate model, define the schema, and validate the implementation with representative data.

A pre-ingestion checklist

Before wiring a producer to a storage target, check that every reading can answer all of these:

□ Which device or sensor group produced it?
□ Which physical quantity does it represent?
□ What timestamp represents the observation time?
□ What are the expected unit, type, and collection frequency?
□ Which query, dashboard, or investigation will use it?

This is not busywork. It is what makes a future time-range query, trend comparison, or troubleshooting session interpretable.

Apache IoTDB is an Apache open-source project for time-series and IoT workloads. For terminology and current data-model concepts, start with the Basic Concepts guide:

Basic Concepts | IoTDB Website

Basic Concepts 1. General Time Series Database Concepts This section introduces basic concepts commonly used in time series databases, including time series data, time series, d...

iotdb.apache.org

What Makes a Time-Series Database IoT-Native?

Timecho — Thu, 10 Sep 2026 02:59:14 +0000

“IoT-native” is an appealing label, but it is most useful when it describes a concrete engineering fit.

Every database can store a timestamped record. That fact alone does not resolve the data-management problems created by connected devices. In industrial IoT systems, measurements arrive continuously from many assets. They may be reported at different frequencies, grouped according to real-world equipment hierarchies, delayed by a gateway or connection, and queried later alongside a much longer operating history.

An IoT-native time-series database is designed with those conditions in view. Apache IoTDB is an Apache open-source project built around this kind of workload. Its value is easier to understand by looking at the questions engineers face before a dashboard, alert, or model is ever built.

A timestamp is necessary, but it is not the whole data model

A conventional record can represent a value and the time it was recorded. Device data usually needs more context. A temperature reading is meaningful only when a team can associate it with a particular asset, measurement point, location in the equipment hierarchy, and observation time.

That is why the organization of measurements matters. Apache IoTDB provides hierarchical measurement-point management aligned with industrial device hierarchies. In practice, this gives engineers a way to reason about data in terms close to the systems being observed: devices, their measurements, and the relationships among them. The precise schema should still follow the needs of each deployment, but the underlying workload is not a flat stream of unrelated values.

IoT streams are rarely uniform or perfectly ordered

In a connected environment, a vibration sensor may report much more frequently than a temperature probe. A network interruption can delay delivery. An edge gateway may buffer measurements and forward them later. As a result, data that was observed earlier can arrive after data with a later timestamp.

This is why “can ingest data” is not a sufficient requirement for an IoT system. Engineers need to consider whether the data path accommodates multi-frequency and out-of-order measurements while keeping the time context intact.

Apache IoTDB supports high-speed ingestion of out-of-order and multi-frequency data. This is not a promise that every ingestion pipeline will behave identically; throughput and configuration remain workload-specific. It identifies the kind of data behavior the project is built to address.

Current operations need historical context

Real-time views help a team see what is happening now. They become more useful when they can be interpreted with historical context. Is a current reading within a normal range for this asset? Did a change begin gradually? Does it coincide with a change in another measurement?

Apache IoTDB brings historical and real-time data management together. That is a useful architectural idea: operational monitoring and longer-horizon investigation should not be treated as unrelated data problems merely because they happen at different moments.

Time-aware questions should be first-class questions

Time-series work is not only about filtering records between two dates. It often includes aggregation over time windows, comparing signals that were sampled at different rates, and aligning timestamps before values are interpreted together.

Apache IoTDB includes a native time-series computation engine, timestamp alignment during queries, and more than 100 built-in aggregation and time-series functions. The exact functions and syntax should always be checked against the current release being used. The broader point is stable: an IoT workload needs data tooling that treats time as part of the question, not as an afterthought.

IoT-native does not remove the need for workload design

No database label substitutes for an engineering decision. Before evaluating a deployment, teams should map their own device count, measurement model, reporting frequencies, retention expectations, query windows, availability needs, and integration path. A data model that is clear for a pilot can become difficult to operate when devices, measurements, and users multiply.

That is also why documentation-led evaluation matters. Teams should start with the release and deployment model under consideration, then validate the schema and query patterns with representative data before drawing conclusions about resource use or operational results. “IoT-native” is a description of workload orientation, not a substitute for those checks.

A practical way to evaluate “IoT-native”

Rather than treat the phrase as a marketing claim, use it as an architecture checklist:

Does the system represent the hierarchy of assets and measurements clearly?
Can it handle measurements that arrive at different rates or out of timestamp order?
Can teams work with current signals and historical data in one coherent model?
Do the available query capabilities support the time-aware questions the operation actually asks?

Apache IoTDB is designed around these time-series and IoT conditions as an Apache open-source project. For a deployment decision, the next step is to validate the current documentation, data model, version, and workload requirements against those questions.

Explore Apache IoTDB and its capabilities: https://iotdb.apache.org/

DB AI: From Data Infrastructure to Industrial Intelligence

Timecho — Fri, 04 Sep 2026 07:35:15 +0000

Hosted by the Open Source Technology Committee of the China Institute of Communications and organized by Timecho, the 2026 Time Series Tech Innovation Summit took place on August 22 at Crowne Plaza Beijing Lido.

Centered on the theme DB × AI, the summit featured one main forum, one technical forum, and two case‑study forums. Moving from strategic outlooks and technology deep dives to real-world industry applications, the summit explored how DB × AI innovations can be translated into practical industrial value.

The event drew 504 on-site participants and approximately 180,000 online viewers, bringing together perspectives from academia, industry, and the open-source community.

Opening Ceremony: Data Arrives On‑Site

The summit opened with the short film Data Arrives On-Site. Drawing on real-world industrial sensor signals, the video illustrated the full lifecycle of time-series data: real-time generation, high-speed streaming, database ingestion and management, AI-powered analysis and prediction, and feedback to physical systems in wind power, energy storage, rail transit, smart manufacturing, and aerospace scenarios.

Humanoid robot Tico stepped onto the stage, bringing the data-driven concept to life. Real-time, multidimensional metrics, including joint dynamics and posture, were displayed on screen alongside live time-series prediction outputs powered by TimechoAI. A Jeet Kune Do performance further demonstrated the continuous generation, perception, and processing of high-velocity time-series data. This special opening offered a vivid on-site interpretation of the DB × AI theme.

Main Forum: Exploring the Next Frontier of DB × AI

The Main Forum opened with perspectives from leading experts on artificial intelligence, database technology, and industrial data.

Academician Jiaguang Sun of the Chinese Academy of Engineering and Hua Tu, deputy secretary-general of the China Institute of Communications, delivered the opening remarks.

You He, an academician of the Chinese Academy of Engineering and vice chairman of the Chinese Association for Artificial Intelligence, shared perspectives on the evolution and real-world adoption of artificial intelligence.

When Data Meets Intelligence

C. Mohan, a member of the U.S. National Academy of Engineering and a distinguished professor at Hong Kong Baptist University, offered a Silicon Valley perspective on DB × AI. He noted that “AI is becoming increasingly dependent on data” and that “there is major synergistic momentum in the database and AI worlds, and this is an exciting time for researchers as well as for the technologists building these things.”

He emphasized the importance of high-quality data to AI progress and the need for closer collaboration between database and AI technologies, while pointing out persistent challenges involving performance, accuracy, privacy and security, cost, and system complexity.

Professor Jianmin Wang, Dean of the School of Software at Tsinghua University, shared insights into the immense value of industrial time-series data in the AI era. He also introduced the TsFile format and the intelligent applications of Apache IoTDB in industrial settings.

Building a Multimodal Data Intelligence Foundation

Dr. Jialin Qiao, CTO of Timecho, unveiled the newly released Multimodal Time-Series Data Intelligence Software Stack and presented Timecho’s latest DB × AI product roadmap. He highlighted how Timecho is extending its capabilities from time-series data management to multimodal data, time-series foundation models, and intelligent agents, building an increasingly integrated foundation for industrial data and AI applications.

Qiao emphasized that the next stage of database evolution lies in deeper integration with AI. As databases take on a greater role in industrial intelligence, they must also provide the secure, reliable, and production-ready foundation required for mission-critical environments.

From Technology to Industrial Practice

The Main Forum concluded with two real-world perspectives from enterprise practitioners.

Wenjun Huang, General Manager of the Data Intelligence Business Unit at CNPC Kunlun Digital Intelligence, introduced standardized data-acquisition practices across the oil, gas, and petrochemical value chain. These practices supported drilling-risk early-warning models with accuracy above 85%, as well as refining-process prediction and anomaly-diagnosis agents with accuracy above 95%.

Huan Zhang, a technical expert at China Southern Airlines, presented applications of Apache IoTDB for predictive aircraft maintenance. Built on Apache TsFile, the data infrastructure reduced the development cycle for fault early-warning models from hours to minutes, demonstrating how time-series data can enable more intelligent aircraft operations and maintenance.

DB × AI Industry Ecosystem Partnership Initiative

A key highlight of the summit was the official launch of the DB × AI Industry Ecosystem Partnership Initiative.

As DB and AI continue to converge, advancing the industry requires more than innovation from individual technologies or companies. It calls for collaboration across the entire value chain, from academic research and foundational hardware and software to databases, AI technologies, industrial software, and real-world applications. By connecting these capabilities, emerging technologies can be more effectively integrated and translated into practical industrial value.

The initiative is built around three interconnected layers of the DB × AI ecosystem. At the core is a technology innovation ecosystem driven by academic research, expert networks, and collaborative R&D. This is supported by a foundational hardware and software ecosystem encompassing chips and computing power, operating systems, data connectivity, databases and data platforms, AI infrastructure, and industrial software. Together, they support an industry application ecosystem spanning energy and power, aerospace, petrochemicals, advanced manufacturing, rail transit, and energy storage.

Against this broader ecosystem framework, the launch ceremony brought together leading experts and representatives from academia, foundational technology providers, database and AI companies, industrial software developers, and vertical industries to explore opportunities for collaboration and joint innovation.

For Timecho, the initiative marks an important step toward a more open and collaborative DB × AI ecosystem. By connecting more partners and technologies, Timecho aims to accelerate joint innovation, facilitate technology integration, and scale DB × AI into practical solutions that create tangible value across industries.

Technical Forum: Building the Technology Stack for DB × AI

If the Main Forum focused on why DB × AI matters, the Technical Forum focused on how it can be built.

The afternoon technical sessions presented a systematic view of the technology stack behind intelligent time-series applications. With Apache TsFile serving as a unified time-series file layer across edge and cloud environments, the stack brings together three core components—TimechoDB, TimechoAI, and TimechoAgent—forming an end‑to‑end capability chain that spans data governance, model training and inference, and intelligent application delivery.
A Three-Layer Technology Stack for DB × AI

TimechoDB serves as the data foundation, extending beyond traditional numerical time-series data to support multimodal inputs, including images, audio, and video. Its Object data type enables unified time-axis modeling and joint analysis across modalities. The platform also strengthens enterprise-grade security through identity authentication, access control, and data encryption.
TimechoAI provides the AI foundation, powered by the Timer series of time-series foundation models. It streamlines workflows spanning data assessment, data governance, model training, inference, and evaluation. By enabling enterprises to train proprietary time-series models on private operational data, TimechoAI lowers the barriers to bringing industrial data into AI training and inference workflows.
TimechoAgent connects databases, AI models, and human operators at the application layer through Skills, CLI, and MCP interfaces. It can automate tasks such as data querying, data-quality assessment, model prediction, and writing results back to source systems, helping close the gap between database capabilities and AI-powered applications.

From collecting and governing multimodal time-series data, to training and deploying time-series foundation models, and ultimately delivering intelligent applications, the architecture is designed to connect data and intelligence across the full workflow.

To bring this full‑workflow architectural vision into practice, three featured demo themes were available for developers and guests:

TimechoDB × TimechoCLI: Closing the Last Mile for DB × AI
TimechoAI × TimechoCLI: Building Your Private Time‑Series “AI Training Lab”
TsFile × AGI TsFile: Data Bridge for Simulation Training and Real-World System Tuning

Technical Insights and Discussions from Frontline Engineers

The technical forum also brought together R&D engineers from Timecho and members of the Apache IoTDB community to share their latest technical practices and insights on DB × AI.

Yuan Tian, a Database Kernel Engineer at Timecho and an Apache IoTDB PMC Member, explored how time-series databases can evolve to support multimodal industrial data.
Rongzhao Chen, an AI Engineer at Timecho and an Apache IoTDB PMC Member, introduced the infrastructure required for training and inference of time-series foundation models.
Shuolin Li, a Database Kernel Engineer at Timecho and an Apache TsFile PMC Member, discussed how Apache TsFile integrates into the AI data ecosystem.
Xuan Wang, a Full-Stack Engineer at Timecho and an Apache IoTDB PMC Member, explored AI tools that bridge the last mile between databases and AI.
Haonan Hou, a Database Kernel Engineer at Timecho and an Apache IoTDB PMC Member, shared Timecho's practices in security hardening and vulnerability management in TimechoDB.
Zhijia Cao, a Database Kernel Engineer at Timecho and an IoTDB Project Delivery Lead, discussed the underlying principles and practical approaches to IoTDB performance optimization and tuning.

Industry Case Studies: Turning Time-Series Data into Industrial Value
The two case study forums brought together frontline experts and practitioners from sectors including energy and power, new energy, shipbuilding, photovoltaics, oil and gas, energy storage, intelligent computing, and scientific research. Drawing on first-hand project experience, the speakers shared how time-series data technologies are being applied to address real-world challenges, demonstrating the practical value of time-series data technologies, including Apache IoTDB, across industrial scenarios.

Case Study Forum 1 featured speakers from the China Ship Scientific Research Center, Energy China Energy Research Institute, Hygon Information Technology, Southeast University, Shanghai Jiudao Information Technology, CISDI Information Technology, and the China University of Geosciences. Their presentations demonstrated the breadth of time-series database applications across different domains.

Case Study Forum 2 brought together experts and practitioners from the Qinghai Photovoltaic Industry Innovation Center, Qinghai Yellow River Smart Energy Technology, Ketr Technology, Makesense Energy, Tsinghua University, Nanjing Tianfu Software, Harbin Institute of Technology, and Qingdao University of Technology. Their discussions explored practical applications in photovoltaic and energy-storage systems, oil-and-gas pipeline monitoring, energy storage data management, spatiotemporal forecasting, industrial AI infrastructure, cloud-edge-device scenarios, and intelligent industrial assessment.

Together, these cases demonstrated how DB × AI can connect data infrastructure with intelligent applications in real-world IoT environments. From data access and management to forecasting, monitoring, optimization, and intelligent decision-making, they showed that the value of DB × AI lies not only in advancing database and AI technologies separately, but also in bringing them together to address concrete industry needs and create measurable value.

Looking Ahead

Collectively, the summit sessions laid out a clear shift: DB × AI is moving from isolated technology experiments toward integrated data and AI infrastructure—and from infrastructure toward real-world industrial applications.

Industrial systems keep generating massive, complex, and multimodal time‑series data at growing scale, driving the evolution of time‑series databases. Tomorrow’s databases will go well beyond basic data storage. They will structure datasets for AI workflows, bridge raw data with foundation models, underpin end‑user intelligent applications, and empower enterprises to turn endless streams of time‑series signals into actionable, business‑driving intelligence. This marks the next frontier for DB × AI — and it is just the beginning of the journey.

We sincerely thank everyone for sharing insights, presenting field-proven practices, and engaging in in-depth exchanges throughout the event.

Moving forward, Timecho will continue to deepen innovation at the intersection of time-series data and artificial intelligence. Centered on its multimodal time-series data intelligence software stack, Timecho will continue refining its full-stack product and technology ecosystem, covering data management, model training and inference, and intelligent application delivery. Working side by side with users, developers, and industry collaborators, Timecho will accelerate the real-world adoption of secure, robust DB × AI solutions across a broader range of industries, unlocking usable, actionable intelligence from every stream of time-series data.

We look forward to reconnecting with the community at future summits to keep exploring the possibilities of DB × AI together.

TsFile Viewer: Inspect, Visualize, and Validate TsFile Data in Your Browser

Timecho — Fri, 31 Jul 2026 03:31:45 +0000

When working with an Apache TsFile file, developers often need quick answers to a few practical questions:

Is the file healthy and readable?
What devices and measurements are stored inside?
What data types, encodings, and compression methods are used?
Does the data within a specific time range match expectations?

Previously, answering these questions often required command-line tools, custom scripts, or manual file analysis.

Now, with TsFile Viewer, users can inspect TsFile metadata, preview data, visualize trends, and perform file health checks directly in a browser — without writing additional scripts.

1. What Is TsFile Viewer?

TsFileis a high-performance file format designed for efficient storage, writing, and transmission of time-series data. It is an important component of the Apache IoTDB ecosystem.

TsFile Vieweris a visual inspection and analysis tool built specifically for TsFile files. Users can select an existing file or simply drag and drop a .tsfile file into the browser to explore its structure, inspect stored data, and evaluate file health.

The workflow is straightforward: go from "I have a TsFile" to "I understand what is inside it" through a simple path:
Select the file -> Explore the structure -> Filter data -> Analyze or export results.

2. Understand File Structure with Tree and Table Models

TsFile supports different data organization models, and TsFile Viewer provides corresponding metadata views based on the file model.

For Tree Model Files, Users Can View:

File version and time range
Number of devices, measurements, and chunks
Device information and Detailed measurement information
Data time ranges for each device

For Table Model Files, Users Can View:

File version and time range
Number of tables, devices, and measurements
Tag columns and field columns
Data types, encoding methods, and compression methods for each field

Instead of manually parsing file structures layer by layer, developers can quickly understand how data is organized. This makes TsFile Viewer useful for development debugging, data validation, and issue investigation.

3. Find Target Data Faster with Flexible Filtering

TsFile files may contain thousands of devices, measurements, or fields. Locating specific data can be challenging without proper tools.

TsFile Viewer provides flexible data browsing capabilities that allow users to filter data by:

Table
Device
Measurement
Field

Users can also select predefined time ranges, including:

Last 1 hour
Last 6 hours
Last 24 hours
Last 7 days
Last 30 days

Custom start and end time ranges are also supported.

With advanced filtering, column search, and pagination, users can quickly focus on the data they need — even when working with files containing a large number of fields.

Filtered results can be exported as*CSVor **JSON* files for further analysis, sharing, or archiving.

4. Visualize Time-Series Changes with Interactive Trend Charts

Raw time-series data is often difficult to interpret when viewed row by row.

Trend charts make it much easier to identify:

Data fluctuations
Sudden changes
Abnormal patterns
Long-term trends

TsFile Viewer can generate multi-series trend charts based on selected devices, measurements, or fields. Users can filter by time range and zoom into specific periods to analyze detailed changes.

When displaying large-scale time-series curves, TsFile Viewer can apply LTTB (Largest-Triangle-Three-Buckets) downsampling to reduce rendering workload while preserving important characteristics such as:

Peaks
Turning points
Overall trend patterns

As a result, users can explore dense time-series data over long periods more smoothly without losing the most important visual information.

Whether validating data collection results, comparing multiple measurements, or investigating changes during a specific time window, TsFile Viewer helps users understand time-series behavior more efficiently.

5. Check TsFile Health with Single-File or Directory Scanning

Beyond data visualization, TsFile Viewer provides powerful file scanning capabilities to help users quickly evaluate file health.
Two scanning modes are supported:

Single-file scanning
Directory scanning

During scanning, users can monitor real-time progress and detailed logs. Once the scan is complete, TsFile Viewer summarizes key information, including file path, file size, health status, detected issues, and scanning duration.

Scan results are categorized into three levels:

HEALTHY: No issues are detected, and the file can be processed normally.
WARNING: Non-critical reading issues are detected, but the file may still be usable.
ERROR: Structural or critical issues are found that may prevent normal parsing.

The health check mechanism follows the same marker-based sequential traversal approach used by IoTDB. It validates the file progressively, from the overall structure to page-level data, checking file integrity, chunk consistency, timestamp ordering, page time ranges, and consistency between metadata and the actual stored data.

Through these checks, TsFile Viewer can help identify common issues such as incomplete files, incompatible formats, structural damage, abnormal data reading, duplicated or unordered timestamps, overlapping time ranges, and inconsistent page metadata.

For scenarios such as batch file validation, troubleshooting data ingestion issues, or quickly confirming whether a TsFile can be parsed successfully, TsFile Viewer provides a clear and efficient way to understand file health without relying on additional scripts or manual inspection.

6. Common Use Cases for TsFile Viewer

Development and Debugging
Quickly verify generated TsFile files and confirm whether devices, measurements, fields, and stored data match expectations.

Testing and Quality Assurance
Inspect metadata, preview stored data, and scan file health to identify structural or data-related issues.

Operations and Troubleshooting
Use time filtering, trend visualization, and scanning reports to narrow down problems and reduce the need for temporary scripts.

Data Delivery and Collaboration
Present TsFile contents visually and export selected data as CSV or JSON for downstream processing and communication.

7. Get Started in Three Simple Steps

Step 1: Download and Launch TsFile Viewer
Visit the Apache TsFile Viewer GitHub project and follow the README instructions to prepare the environment and launch the application.

For development mode, start the backend and frontend services separately, then access:http://localhost:5173/view/

For production deployment, build the distribution package and start the application using the generated JAR package, then access:http://localhost:8080/view/

You can then enter the TsFile Viewer interface directly through your browser.

Step 2: Upload a TsFile
Select an existing TsFile file, or drag and drop a .tsfile file into TsFile Viewer.

Step 3: Explore and Analyze
Choose the functions you need:

Metadata inspection
Data preview
Chart visualization
File health scanning

From file structure to data content, and from trend analysis to health diagnostics, TsFile Viewer makes TsFile exploration and troubleshooting more visual, efficient, and accessible.

Start using TsFile Viewer today and quickly understand your TsFile data.

Apache IoTDB in Connected Vehicle Management: Scaling Telemetry for Millions

Timecho — Thu, 16 Apr 2026 06:32:00 +0000

Modern connected vehicle platforms generate massive, high-frequency telemetry under variable connectivity, creating unique challenges for real-time ingestion, millisecond-level per-vehicle queries, and fleet-wide analytics.

Building on our previous articles—"Powering Intelligent Transportation with Apache IoTDB: Managing Time-Series Data at Scale" and "Apache IoTDB in Urban Rail Operations and Maintenance—Use Cases and Technical Deep Dive"—this article presents use cases from Connected Vehicle Management Scenarios how IoTDB's time-series–native architecture with TsFile compression efficiently supports millions of vehicles while reducing infrastructure footprint and operational complexity.

The Scale Challenge in Connected Vehicles

Managing 1.6 million vehicles, 800,000 concurrently active, producing 20 TB/day, introduces unique technical challenges:

High concurrency writes: Millions of vehicles transmit telemetry simultaneously, often unpredictably.
Per-vehicle queries: Remote diagnostics require millisecond-level access to individual vehicle data.
Fleet-wide analytics: Aggregations across millions of vehicles must complete in seconds, not hours.
Variable connectivity: Data arrives out-of-order due to network gaps, tunnels, and parking garages.
Surge capacity: Holidays and events trigger acute traffic spikes that must be absorbed without service degradation.

Safety, compliance, and business-critical decisions all depend on reliable, real-time telemetry ingestion and querying.

Case 1: Changan Automobile—570,000 Vehicles, 1 IoTDB Instance

Background

Changan's connected vehicle platform supports real-time driver assistance, remote diagnostics, and predictive maintenance. Previously, HBase required 25 nodes to handle ingestion and queries for 80 million measurement points across 150 million time-series.

Migration to IoTDB

Single-node deployment replaced 25 HBase nodes.
Real-time write: Tens of millions of data points per second sustained.
Query latency: Minutes-to-milliseconds reduction for per-vehicle time-range scans
Latest-value retrieval: Millisecond responses from in-memory buffers.
Compression efficiency: TsFile reduces storage and I/O by 10–30×, lowering infrastructure needs.

Why it works

IoTDB's columnar format stores each measurement channel independently, enabling high-throughput writes and per-vehicle queries without scanning irrelevant data. Combined with TsFile compression, it significantly reduces hardware and operational overhead.

Case 2: AutoAI—1.6 Million Vehicles, 20 TB/day

Background

Supports Toyota driving behavior analytics. Beyond raw telemetry, the platform performs fleet-wide pattern analysis, driving safety scores, and regulatory reporting. Previously HBase with heavy application-layer logic was used.

Key Results after IoTDB Migration

Infrastructure: Reduced to 25–33% cost of previous HBase deployment.
Storage: Cut to 1/10 of prior footprint.
Peak throughput: 2M points/sec sustained during commute and holiday peaks.
Fleet-wide analytics: Trailing 15–30 minute queries over 1.6M vehicles now complete in seconds.
Operational simplicity: Ingestion and query separation prevents write spikes from slowing analytics; cluster scales dynamically without downtime.

Architectural highlights

Path-based schema: supports per-vehicle, regional, system-level, and cross-fleet queries efficiently.
Out-of-order writes: IoTDB inserts late-arriving data correctly without application-layer buffering.
Sensor-aware compression: Delta encoding for monotonic values, run-length for binary signals.
Analytics integration: Direct access via JDBC/SQL, Spark/Flink, REST, and Kafka pipelines.

Comparative Insights: Connected Vehicles vs. Urban Rail

Aspect	Connected Vehicles	Urban Rail
Write patterns	Variable-frequency, unpredictable telemetry from millions of moving vehicles	Fixed-route, predictable telemetry from trains on known schedules
Query patterns	Recent-window fleet analytics and millisecond per-vehicle lookups	Deep historical maintenance queries over months/years
Infrastructure impact	More dramatic server consolidation due to HBase inefficiency with high-cardinality per-sensor queries	Moderate consolidation; edge + central clusters suffice
Connectivity handling	Must tolerate intermittent connectivity, out-of-order data	Edge synchronization handles occasional connectivity gaps
Platform flexibility	Same IoTDB platform supports both workloads without architectural compromise	Same IoTDB platform supports both workloads without architectural compromise

The same IoTDB platform accommodates both domains without architectural compromise.

Summary

Apache IoTDB enables real-time ingestion, efficient columnar storage, and low-latency per-vehicle and fleet-wide queries at production scale. Infrastructure is reduced, operational complexity lowered, and analytics accelerated.

Its architecture scales with increasing vehicle count, sensor density, and analytics demands without requiring fundamental re-engineering of the data layer.

Apache IoTDB in Urban Rail Operations and Maintenance—Use Cases and Technical Deep Dive

Timecho — Tue, 14 Apr 2026 03:31:00 +0000

The Data Intensity of Modern Rail Systems

Urban rail operations produce telemetry at extreme scale. A single metro train typically carries hundreds of sensors monitoring traction, braking, doors, HVAC, wheel wear, pantograph force, and other subsystems. At fleet scale—hundreds of trains plus trackside and station systems—the data volume becomes operationally significant.

In one representative deployment, the platform ingests 414 billion data points per day from a single metro management system. At this scale, data infrastructure directly affects reliability. Delayed ingestion can hide early fault signals; slow queries reduce operational visibility during incidents; inefficient storage drives unsustainable infrastructure costs. These constraints define the database requirements for rail O&M platforms.

This article analyzes how Apache IoTDB addresses these challenges across three production deployments.

We previously discussed the differences between Apache IoTDB as a time-series database and traditional databases. This article focuses on real-world application scenarios. If you need background context, please refer to: "Apache IoTDB for Intelligent Transportation — Architecture, Core Capabilities, and Industry Fit".

The Urban Rail Data Problem

High Measurement Density

A typical train exposes 1,000–5,000 measurement channels. Across a 300-train fleet, that expands to 300,000–1.5 million active time series, quickly reaching petabyte-scale raw volumes without compression.

Mixed Real-Time and Historical Workloads

Rail O&M systems must handle:

Continuous high-frequency ingestion
Real-time latest-value queries
Long-range historical analysis
Sliding-window anomaly detection

Many general-purpose databases optimize for only one of these patterns, leading to performance trade-offs at scale.

Complex Metadata Hierarchies

Rail telemetry carries structured context: train ID, car position, subsystem, sensor type, installation location, and maintenance lineage. Maintaining consistency across millions of series becomes operationally expensive in loosely coupled architectures.

Long Retention with Tiered Access

Operational and regulatory requirements typically mandate multi-year retention:

Hot data (≤30 days): frequently queried
Warm data (30 days–2 years): periodic analysis
Cold data (>2 years): compliance access

Efficiently serving all tiers without manual migration is a core requirement.

Case 1: CRRC Sifang—Fleet-Scale Intelligent O&M

Background

CRRC Sifang operates intelligent maintenance platforms for metro fleets, enabling condition-based maintenance and fault diagnostics. The previous stack—KairosDB—began to show limits in storage efficiency, metadata management, and write/query latency as scale increased.

Deployment Scale

300 metro trains under management
Nearly 1 million active measurement points
414 billion data points per day
Multi-year retention requirement

Average sustained ingestion reaches approximately 4.8 million points per second, with higher bursts during operational peaks.

Why the Migration Happened

The team faced three growing pressures:

Storage costs rising faster than fleet growth
Query/Write latency increasing with data increase
Metadata management requiring manual intervention

Results After Migrating to IoTDB

Schema-aligned metadata IoTDB's hierarchical model (network → line → train → car → subsystem → sensor) matches rail topology directly. Metadata becomes schema-native, removing external synchronization overhead.
Write efficiency and infrastructure reduction IoTDB sustained full ingestion volume while reducing the deployment from 9 servers to 1, significantly lowering operational complexity.
Storage compression Three-year storage footprint dropped from 200 TB to 16 TB (≈92.5% reduction), driven by time-series–optimized TsFile compression.
Query responsiveness Sampling latency improved by 60% Managed train capacity doubled on the same infrastructure Monthly incremental data volume reduced by 95%
Operational impact The platform can now expand monitoring coverage without proportional infrastructure growth, improving the economics of large-scale fleet observability.

Case 2: Metro Automation Platform—Replacing Cassandra in Cloud Signaling

Background

This deployment supports a cloud-based metro automation and signaling system spanning multiple stations with dual data centers. The workload combines sustained high-throughput ingestion with strict query latency requirements.

The previous architecture used Apache Cassandra. While write throughput was acceptable, time-range aggregation queries and resource efficiency became bottlenecks.

Deployment Characteristics

Dozens of fully instrumented stations
Active-active dual data centers
Sustained million-level read/write throughput
Mixed real-time and historical queries

Why the Traditional Database No Longer Fit

Cassandra's denormalization model increases storage overhead and operational complexity for time-series workloads that require flexible temporal aggregation. In addition, the lack of native time-series compression causes storage costs to scale roughly linearly with data volume.

IoTDB Results

After migration:

Query performance improved by 120%
Resource consumption reduced by 60% (CPU, memory, I/O)
Million-level throughput sustained without additional horizontal expansion

For signaling systems, reduced query latency directly improves control-loop responsiveness.

Toward Cloud-Based Train Control

The platform is extending IoTDB into cloud signaling workloads with stricter latency and availability requirements. IoTDB's distributed cluster architecture and automatic failover align well with the platform's dual–data center topology, enabling high availability without manual intervention.

Case 3: Deutsche Bahn—Fuel Cell Monitoring for Rail Infrastructure

Background

The Deutsche Bahn BZ-NEA project modernizes backup power systems at railway facilities using hydrogen fuel cells. These electrochemical systems require continuous, high-resolution monitoring across multiple interacting parameters.

Operational Requirements

The platform must support:

Compliance with safety regulations
Safe operation of battery systems
Real-time query performance
Real-time anomaly detection

Fault conditions can escalate rapidly, making second-level telemetry and low-latency queries essential.

Why IoTDB Was Selected

Safety and compliance readiness The monitoring platform required strict data integrity and availability guarantees. IoTDB's open-source transparency and configurable replication model supported compliance validation.
Real-time visibility Second-level ingestion combined with millisecond query response enables early fault detection.
Built-in support for anomaly detection workloads The system runs anomaly detection directly against IoTDB, using both real-time streams and historical baselines through a unified query path.

Industry Implication

This deployment demonstrates that IoTDB's applicability extends beyond rolling stock telemetry into broader rail infrastructure monitoring scenarios with similar data characteristics.

Key Architectural Takeaways

Across these deployments, several consistent design patterns emerge:

Edge-to-central ingestion enables reliable data collection despite intermittent connectivity.
Hierarchy-aligned schema design simplifies fleet-scale queries without denormalization.
Native tiered storage supports multi-year retention with minimal operational overhead.
Ecosystem integration allows the same data platform to serve both real-time and batch analytics.

Summary

Apache IoTDB proves highly effective in urban rail operations, supporting real-time writes, efficient storage, and low-latency queries. Its time-series–native design scales operationally without extra infrastructure, making it ideal for modern rail O&M systems.

The next article explores connected vehicle applications, applying the same principles to a different domain.

Stay tuned!

Timer-S1 Released: The First Billion-Scale Time Series Foundation Model Achieving SOTA Performance

Timecho — Mon, 13 Apr 2026 02:28:00 +0000

Introduction of Timer

As AI continues to permeate industrial systems, the role of time series data has evolved beyond basic querying and analytics toward more advanced tasks such as equipment state forecasting and intelligent imputation of missing data. Achieving high-precision forecasting in these scenarios increasingly depends on foundation models that are purpose-built for time series characteristics.

However, unlike text, images, or video, time series data presents unique challenges: high variability, stochasticity, and complex temporal dependencies. These factors significantly limit the generalization and scalability of traditional models. As a result, developing domain-specific foundation models for time series has become a central focus in both academia and industry.

To address these challenges, the research team from Tsinghua University, in collaboration with ByteDance, introduces Timer-S1, the latest advancement in the Timer model series (Timer 1.0–3.0). Timer-S1 is the first time series foundation model scaled to billions of parameters, with a context length of up to 11.5K time steps. It achieves state-of-the-art (SOTA) forecasting performance on the large-scale benchmark GIFT-Eval.

The accompanying paper, "Timer-S1: A Billion-Scale Time Series Foundation Model with Serial Scaling," presents the technical details. In this article, we break down the key innovations behind Timer-S1.

Core Challenges in Time Series Foundation Models

Building foundation models for time series involves several fundamental challenges:

Strong Data Heterogeneity

Time series data varies significantly across domains in terms of frequency, distribution, and structure. Capturing multi-scale dependencies in high-dimensional, often unstructured signals remains difficult.

Intrinsic Uncertainty

Real-world time series are typically non-stationary and stochastic. External factors and system dynamics can introduce abrupt distribution shifts, increasing prediction uncertainty.

Scalability Constraints

Scaling techniques widely used in large language models—such as Mixture-of-Experts (MoE)—do not directly translate well to time series, often leading to degraded performance. Balancing sequential dependency modeling with computational efficiency remains a bottleneck.

Training–Inference Gap

Autoregressive models align well with the sequential nature of time series, but suffer from high computational cost and error accumulation during iterative inference. On the other hand, parallel multi-step prediction improves efficiency but fails to capture long-term dependencies.

Timer-S1 is designed as a systematic response to these challenges.

Core Innovation of Timer-S1: The Serial Scaling Paradigm

The key contribution of Timer-S1 is the introduction of a serial scaling paradigm, which integrates the sequential nature of time series forecasting into three tightly coupled dimensions: model architecture, dataset construction, and training pipeline.

Architecture Design: Efficient Serial Forecasting

Timer-S1 is built on a decoder-only Transformer backbone, enhanced with two specialized modules:

TimeMoE Block

A sparse Mixture-of-Experts module tailored for global heterogeneity in time series. It dynamically routes different temporal patterns to specialized experts, enabling:

Scalable training up to 8.3 billion parameters
Improved training stability
Efficient inference despite large model size

TimeSTP Block (Serial Token Prediction)

The core innovation for sequential forecasting. TimeSTP introduces progressive, step-wise prediction within a single forward pass:

TimeSTP is a time-series modeling approach that captures temporal dependencies in sequential data to enable accurate forecasting and pattern analysis.

Iteratively generates multi-step forecasts using historical inputs and intermediate representations
Eliminates the need for autoregressive rolling inference
Reduces error accumulation while significantly improving inference efficiency

Unified Forecasting Head

A shared quantile prediction head that supports multiple output formulations (e.g., linear projection, diffusion-based heads), ensuring architectural flexibility.

The Timer-S1 Model increased additional techniques include:

Instance-wise re-normalization to handle scale variations across datasets
Patch-level tokenization, converting continuous time points into model-friendly tokens

Data Construction: A Trillion-Point Time Series Corpus

To support large-scale training, the team constructed TimeBench, a dataset containing 1 trillion time points.

Key features include:

Multi-Source Data Integration

Combines real-world datasets from finance, IoT, meteorology, and healthcare, along with public benchmarks (e.g., Chronos, LOTSA), and synthetic signals (linear, sinusoidal, exponential).

Strict Data Quality Control

Missing values handled via causal mean imputation
Outliers removed using sliding-window detection
Data leakage prevention through rigorous filtering

Targeted Data Augmentation

Resampling
Value flipping

These techniques reduce prediction bias and improve generalization.

Data Complexity Evaluation

Each dataset is profiled using:

ADF stationarity tests
Spectral entropy-based predictability metrics

This results in a structured "complexity plane" for fine-grained dataset selection.

Training Pipeline: Optimizing Short and Long-Term Forecasting

Timer-S1 adopts a multi-stage training strategy instead of a single-phase approach:

Pretraining

Dense supervision across varying input-output lengths using STP as the core objective, enabling strong representation learning and multi-steps forecasting ability.

Continued Pretraining

Introduces a weighted STP objective to prioritize short-term accuracy (critical for long-horizon forecasting), combined with replay-based sampling to prevent overfitting.

Long-Context Extension

Using RoPE (Rotary Positional Embedding), the context length is extended from 2,880 to 11,520 time steps, significantly improving long-range dependency modeling.

The training system supports:

Billion-scale distributed training
Hybrid memory–disk data loading for efficient trillion-scale data access

Benchmark Results: SOTA on GIFT-Eval

Timer-S1 is evaluated on GIFT-Eval, a comprehensive benchmark with:

24 datasets
144,000 time series
177 million data points

Key Results:

Overall SOTA Performance

MASE ↓ 7.6% (Mean Absolute Scaled Error)
CRPS ↓ 13.2% (Continuous Ranked Probability Score)

Compared to Timer-3 (trained on the same TimeBench dataset), these results demonstrate the effectiveness of the serial scaling paradigm.

Strong Mid- and Long-Horizon Forecasting

Performance gains are especially pronounced for longer prediction horizons, validating the effectiveness of serial modeling in capturing long-term dependencies.

Significant Gains from Post-Training

Multi-stage training (include pretraining, continous pretraining and long context expansion) significantly outperforms single-stage pretraining, confirming the importance of decoupled optimization objectives.

STP vs. NTP/MTP

Under the same compute budget:

STP outperforms both Next Token Prediction (NTP) and Multi-Token Prediction (MTP)
Achieves better accuracy with lower inference latency

Ablation Studies: Core Component is Essential

Extensive ablation experiments highlight the importance of each component:

TimeSTP Design Matters Removing TimeSTP during inference or reverting to autoregressive rolling prediction leads to substantial performance degradation. The current design effectively narrows the gap between training and inference, adapting to the distribution characteristics of time series.

Data Augmentation is Critical Eliminating augmentation strategies (resampling and value flipping) increases prediction bias and reduces generalization, which validates the necessity of data augmentation in alleviating time series distribution imbalance.

Pretraining Enables Transferability Models trained from scratch perform significantly worse, demonstrating strong cross-task knowledge transfer from TimeBench.

Scaling Still Works Optimal performance is achieved with 24 TimeMoE blocks + 16 TimeSTP blocks, confirming that billion-scale expansion continues to yield gains.

Conclusion

Timer-S1 represents a major step forward in scaling time series foundation models to the billion-parameter regime. Its serial scaling paradigm systematically integrates the sequential nature of time series into architecture, data, and training, offering a generalizable solution to long-standing scalability challenges.

With innovations such as TimeBench, multi-stage training, and the TimeSTP module, Timer-S1 provides a reusable technical framework for future research and industrial deployment.

The release of Timer-S1 is not an endpoint, but a new milestone. Continued advancements in generalization and real-world applicability will further unlock the potential of time series intelligence across industries.

Bringing Time-Series Forecasting into Apache IoTDB Database

Timecho — Wed, 08 Apr 2026 02:26:00 +0000

A Covariate Forecasting Framework with TimechoDB AINode

In industrial time-series forecasting scenarios, accurate trend prediction often serves as a critical foundation for operational decision-making. However, traditional univariate forecasting approaches struggle to fully capture the complexity of real-world systems.

Take electricity pricing as an example. Power prices are not determined solely by historical price patterns. They are also influenced by a variety of external factors, including temperature, wind speed, holidays, and energy supply structure. Similar multivariate dependencies exist across many industries, such as manufacturing, transportation, and energy systems.

As the scale and complexity of time-series data continue to grow, forecasting is no longer purely an algorithmic problem. Increasingly, it requires tight integration between data infrastructure and model capabilities.

In TimechoDB, we significantly enhanced the capabilities of AINode, the database's intelligent analysis node. The upgrade enables native deployment and inference of Transformer-based time-series models, while introducing a framework for covariate-aware forecasting tasks.

With this capability, users can integrate different types of time-series foundation models directly into the database, enabling a unified workflow that spans data management, model execution, and predictive analytics.

What Are Covariates and Covariate Forecasting?

To understand covariate forecasting, it is important to first clarify two core concepts.

Covariates

Covariates are variables that are strongly correlated with the target variable and can provide additional information useful for prediction.

For example, in electricity price forecasting:

Temperature
Wind speed
Holiday indicators
...

influence fluctuations in power prices. These variables can therefore be used as covariates during model training and inference.

Covariate Forecasting

Unlike univariate forecasting methods, covariate forecasting combines:

Historical data of the target variable
Historical data of covariates
Partially known future covariate values

to jointly model future trends.

Instead of relying on a single time series, the model learns from the dynamic relationships across multiple data dimensions, allowing it to better reflect the underlying behavior of real-world systems.

By incorporating covariate information, forecasting models can move beyond the limitations of single-signal prediction. In many industrial applications, this leads to significantly improved prediction accuracy and stability.

AINode: A Database-Native Intelligent Analysis Node

To better integrate forecasting capabilities with data infrastructure, TimechoDB introduced a major upgrade to AINode in version 2.0.8.

AINode is designed to transform the database from a pure data management system into a platform that can also host model deployment and inference workloads. This enables predictive analytics to run directly within the database environment.

In this release, AINode provides a unified model integration mechanism that allows the database to deploy a variety of Transformer-based time-series models, including:

Timer
Chronos
Moirai
...

Model training can still be performed outside the database for maximum flexibility. However, model deployment, inference execution, and task scheduling are centrally managed within the database.

With this architecture, forecasting tasks can directly:

Read data from the database
Invoke the prediction model
Generate forecast results

This eliminates the frequent data exports and system switching common in traditional forecasting pipelines.

As a result, the database evolves from a standalone data store into an infrastructure layer that enables collaboration between data and AI workloads.

Native Forecasting with SQL

In many forecasting tools, covariates must be manually passed as parameters. Users often need to input covariate values one by one in SQL queries or construct them via string concatenation.

This approach introduces several issues:

Complex operational workflows
Higher risk of parameter input errors
Limited integration with existing data query processes

TimechoDB optimizes this process by allowing covariate inputs to be directly queried from the database using SQL. This makes forecasting tasks a natural extension of standard data query workflows.

A typical covariate forecasting call looks like the following:

SELECT * FROM FORECAST (
    MODEL_ID => 'chronos2',
    TARGETS => (
        SELECT TIME, target1, target2
        FROM etth.tab_real
        WHERE TIME < 7
        ORDER BY TIME DESC
        LIMIT 6
    ),
    HISTORY_COVS => (
        SELECT TIME, cov1, cov2, cov3
        FROM etth.tab_real
        WHERE TIME < 7
        ORDER BY TIME DESC
        LIMIT 6
    ),
    FUTURE_COVS => (
        SELECT TIME, cov1
        FROM etth.tab_real
        WHERE TIME >= 7
        LIMIT 2
    ),
    OUTPUT_LENGTH => 2
);

With this approach:

Target variables and covariates both come directly from database queries
No manual parameter concatenation is required
Forecasting workflows become significantly easier to implement

This greatly lowers the operational barrier for deploying forecasting tasks.

Industrial Case Study: Covariate Forecasting for Electricity Prices

Covariate forecasting is not only a theoretical capability — it also delivers measurable benefits in real industrial scenarios.

In a real-world electricity price forecasting task, we validated the covariate forecasting framework under production conditions.

The goal was to predict electricity price trends. However, electricity prices are influenced by many interacting factors, including:

Meteorological conditions
Time-related patterns
Energy supply structures

In addition, extreme price spikes are notoriously difficult to predict.

During the modeling process, the business team initially identified more than 100 potential covariates. After multiple rounds of data cleaning and feature selection, over 20 key variables were retained for the final model.

These variables can be broadly grouped into three categories:

Time-related variables, such as date, weekday indicators, and holiday indicators, which capture periodic patterns in electricity demand.

Weather-related variables, including temperature, wind speed, precipitation, and cloud coverage, all of which can significantly influence energy consumption and renewable generation.

Energy-related variables, such as solar power generation, wind power output, and energy conversion efficiency, reflecting the supply-side dynamics of the energy system.

During forecasting, the model simultaneously consumes:

2,880 historical timestamps (~30 days) of target variables and covariates
160 future timestamps(~40 hours) of known covariate information

We implemented a covariate-enhanced forecasting approach built on top of open-source time-series foundation models and compared it against several baseline models.

The experimental results show that in complex multivariate environments, incorporating covariate modeling allows prediction curves to capture real trend changes more accurately. The covariate-enhanced model outperformed baseline models in:

Peak prediction accuracy
Trend tracking
Overall stability

In particular, the FutureBoosting covariate-enhanced model was able to better align with actual series behavior during key trend transitions.

Multi-model forecasting comparison: the covariate-enhanced approach (FutureBoosting) aligns more closely with the ground-truth series, particularly during major trend shifts.

Conclusion

In TimechoDB v2.0.8, we introduced a major upgrade to AINode, enabling the database to deploy and run Transformer-based time-series models while providing a framework for covariate forecasting tasks.

With this capability, organizations can centrally manage:

Model deployment
Forecasting task scheduling
Data access

all within the database environment.

This architecture enables an integrated workflow that spans data management and intelligent analytics.

As time-series foundation models continue to evolve, the collaboration between databases and AI models will increasingly become a key direction for next-generation time-series data systems. Databases are gradually evolving into critical infrastructure for time-series AI applications.

Apache IoTDB for Intelligent Transportation — Architecture, Core Capabilities, and Industry Fit

Timecho — Tue, 07 Apr 2026 03:17:00 +0000

The Data Infrastructure Problem Layer Often Overlooked

When intelligent transportation is discussed, the focus typically falls on autonomous vehicles, smart signaling, and real-time routing. Rarely does attention turn to the data infrastructure layer that quietly sustains these systems—continuously ingesting millions of sensor readings per second, compacting years of telemetry into manageable storage, and serving operational queries in milliseconds while transportation systems operate at full speed.

Yet in production environments, this invisible layer often determines whether an intelligent transportation platform scales successfully.

Consider the data reality:

A modern metro system operating 300 trains can generate ~414 billion data points per day
A connected vehicle platform managing 1.6 million vehicles can produce ~20 TB of new telemetry every 24 hours

These are not traditional data warehousing workloads. They are high-cardinality, high-velocity time-series problems that require purpose-built infrastructure.

Apache IoTDB is designed for exactly this class of workload. This article examines what it is, why it fits transportation systems particularly well, and where it delivers the most operational value.

What Is Apache IoTDB?

Apache IoTDB (Internet of Things Database) is an open-source, high-performance and AI-ready time-series database under the Apache Software Foundation. It was originally engineered for industrial IoT environments characterized by extreme write throughput and long-term telemetry retention—conditions that closely mirror modern transportation systems.

At a systems level, IoTDB differentiates itself through three architectural principles.

Purpose-Built for Time-Series at Scale

IoTDB is not a general database retrofitted with time-series features. Its:

Data model
Indexing strategy
Query engine
Storage format

are all optimized for canonical time-series access patterns, including:

High-frequency sequential writes
Time-range scans
Long-window aggregations
...

This specialization eliminates much of the structural overhead seen in row-oriented or general distributed databases under fleet-scale workloads.

Native Columnar Storage: Apache TsFile

IoTDB uses Apache TsFile as its on-disk format, organizing data by measurement and time to maximize compression efficiency.

For transportation telemetry—where sensor values typically exhibit strong temporal locality—TsFile commonly achieves 10×–30× lossless compression in production environments. In real deployments, three-year storage footprints have been reduced from 200 TB to ~16 TB.

Edge-to-Cloud Native Architecture

Unlike databases designed primarily for centralized deployment, IoTDB was built with edge scenarios as a first-class requirement.

Edge nodes (vehicles, substations, vessels) accumulate data locally and synchronize compressed TsFile segments upstream. Compared with record-level replication, this approach can reduce bandwidth consumption by up to 90%—a material advantage in environments with intermittent or constrained connectivity.

Why Traditional Databases Struggle at Transportation Scale

Transportation telemetry exposes several structural weaknesses in non-specialized databases.

Row-oriented storage Time-range queries against row stores incur significant I/O amplification because sensor histories are interleaved across rows. At fleet scale, this frequently translates into minute-level latency.
Generic distributed schemas Many systems require substantial application-side modeling to represent hierarchical assets (fleet → vehicle → subsystem → sensor). Metadata management often becomes a bottleneck at million-series scale.
Inefficient time-series compression Storage engines without time-series-aware encoding typically scale storage cost roughly linearly with data volume—economically unsustainable for multi-year telemetry retention.
Licensing and deployment flexibility Some database licensing models impose constraints on self-hosted deployment, long-term cost predictability, or deep system customization. For transportation platforms that operate large, long-lived infrastructure systems, these limitations can introduce operational and architectural friction at scale.

These limitations consistently surface in production migrations toward purpose-built time-series infrastructure.

Core Technical Capabilities

High-Throughput Ingestion

IoTDB's write path is optimized for concurrent, high-frequency sensor ingestion. In production conditions, a single node can sustain tens of millions of data points per second, enabled by:

Memory-buffered ingestion
Batch-optimized flushing
Time-partitioned storage

For transportation platforms, this means hundreds of trains or hundreds of thousands of vehicles can be absorbed without write-side bottlenecks.

Millisecond-Level Query Performance

Transportation workloads typically fall into three query classes:

Latest-value queries Example: current speed or battery level of a vehicle. → Served from in-memory structures with sub-millisecond latency.
Time-range queries Example: brake pressure between 08:00–09:30. → Executed efficiently via time-partitioned TsFile scans.
Aggregation queries Example: fleet fuel consumption over 30 days. → Accelerated by columnar scan-and-aggregate execution.

Across multiple production deployments, workloads migrated from HBase or Cassandra have observed latency reductions from minutes to milliseconds.

Compression and Storage Efficiency

Transportation telemetry is highly compressible due to:

Temporal correlation within sensor streams
Bounded numeric ranges
Repetitive measurement patterns

TsFile leverages differential encoding, run-length encoding, and dictionary compression at the column level.

In practice, this yields 10×–30× smaller storage footprints, directly lowering infrastructure cost at fleet scale.

Edge-to-Cloud Synchronization

IoTDB enables configurable synchronization strategies — from real-time record-level streaming to compressed TsFile-based batch replication — allowing transportation operators to balance latency, bandwidth efficiency, and network resilience.

This design delivers two operational advantages:

Bandwidth efficiency: Compressed TsFile transfer can reduce network usage by up to 90%.
Offline tolerance: If connectivity drops (tunnels, offshore zones), edge nodes continue buffering locally and resume sync automatically when the network returns—without application-side reconciliation logic.

High Availability Architecture

Distributed IoTDB clusters support:

Automatic failover
Load balancing
Rapid node recovery

For transportation systems where telemetry gaps can impact safety and compliance, these are baseline requirements rather than optional features.

Open Governance and Deployment Flexibility

IoTDB is governed under the Apache License 2.0, providing full source transparency and flexible self-hosted deployment. For large-scale transportation platforms that operate long-lived infrastructure systems, this model supports greater operational control and long-term maintainability.

Where IoTDB Fits in the Transportation Stack

IoTDB is data infrastructure, not an end-user application platform.

What IoTDB Handles

Telemetry ingestion from vehicles and infrastructure
Long-term compressed storage
High-performance time-series querying

What Typically Sits Above

Predictive maintenance systems
Anomaly detection pipelines
Visualization platforms (e.g., Grafana)
Big data processing (Spark, Flink, Hadoop)

What Sits Below

Onboard data collectors
IoT gateways
Network transport layers (5G, DSRC, satellite)

This positioning is important for correctly scoping IoTDB within complex transportation architectures.

Two Primary Transportation Use Domains

Urban Rail Operations and Maintenance

This domain emphasizes:

Equipment health monitoring
Predictive maintenance
Signal integration
Real-time operations

Production deployments include:

CRRC Sifang intelligent rail O&M platform
CityX Urban Construction Intelligent Control metro automation system
Deutsche Bahn fuel cell monitoring project

These environments commonly involve millions of measurement points and multi-year retention requirements.

Connected Vehicle Management

This domain features:

Geographically distributed fleets
Heterogeneous telemetry
Bursty peak loads
Mixed real-time and analytical queries

Representative deployments include:

Changan Automobile connected vehicle platform
AutoAI Toyota driving behavior system

Measurement cardinality typically reaches tens to hundreds of millions of time series.

Summary

Intelligent transportation systems run on time-series data infrastructure that is often overlooked but operationally decisive.

Apache IoTDB addresses the sector's most persistent data challenges through:

High-ratio TsFile compression
Edge-native synchronization
Millisecond query latency
Open and sovereign deployment model

The next two articles in this series examine how these capabilities translate into real-world outcomes in urban rail and connected vehicle platforms. Stay tuned!

Build smarter systems on a foundation that scales. Start exploring IoTDB today.