DEV Community: Timecho

Your First Time-Range Query: A Practical Starting Point for Apache IoTDB

Timecho — Tue, 27 Oct 2026 09:57:03 +0000

Start with one device, one measurement, and a clear interval to turn time-series history into an answerable question.

Most time-series questions start with a window: what happened to this device between two points in time?

An operator may want to inspect a temperature change during a shift. An engineer may need to review vibration before a maintenance event. A developer may be building a chart that shows how a signal moved over the last hour. In each case, “give me the data” is not specific enough. The query needs a subject, a measurement, and a time interval.

Apache IoTDB supports time-oriented queries over IoT measurements. A time-range query is a small building block, but it is also a useful way to make a larger data question precise.

Turn the question into a query scope

Before writing SQL, identify three things:

Which asset or device? Narrow the query to the equipment relevant to the question.
Which measurement? Choose the signal that helps answer it, such as temperature or vibration.
Which time window? State both the start and end of the period you want to inspect.

For example, “How did motor temperature behave during the last hour?” is more actionable than “Show me the motor data.” It identifies an asset, a measurement, and a bounded interval. If the purpose is troubleshooting, the interval might be the period before and after an event. If it is routine monitoring, it might match a shift or operating window.

This framing also helps prevent accidental over-fetching. A query that has no clear time boundary may return more history than the chart, investigation, or application needs. A bounded range makes the intent easier to review and the result easier to handle.

A basic Apache IoTDB time filter

The following example uses the Tree model and an illustrative device path. Replace the path and measurement with names from your own schema:

SELECT temperature
FROM root.factory.line1.motor1
WHERE time >= now() - 1h

This asks for temperature observations from the last hour for one device. The filter uses the time column to restrict the query window. For a historical investigation, use explicit start and end values appropriate to the target IoTDB release and the timestamp precision configured in the environment.

The example is intentionally small. It does not aggregate the readings, interpolate missing points, or combine devices. Those are different analytical decisions and should be added only when the question requires them.

Choose boundaries deliberately

A time range is part of the meaning of a query. “The last hour” is useful for a live view, but a fixed interval can be easier to reproduce during an investigation. Whichever form you choose, decide whether the beginning and end are inclusive, and keep that choice consistent across adjacent queries.

Boundary behavior matters when data is divided into windows. If one query ends at the same timestamp where the next begins and both include the boundary, a point can appear twice. If both exclude it, the point may be missed. A common design is to use a half-open interval: include the start, exclude the end. Verify that the syntax and application logic match the convention you choose.

Also distinguish event time from arrival time. A record received during the selected hour may describe an observation from earlier. If the task is to understand equipment behavior, the query should follow the event timestamp preserved by the ingestion path, not silently substitute processing time.

Keep the device and measurement scope readable

Time-range queries are easier to debug when the path is explicit. A device-oriented path such as root.factory.line1.motor1 communicates which equipment the query addresses. A measurement name such as temperature states what is being retrieved.

In an application, do not concatenate unchecked user input into a query. Validate device paths and measurement names against an allowed schema or metadata source. Validate the requested time bounds and reject ranges that exceed the product or application policy. These are application safeguards around query construction; they are not a replacement for database permissions.

For a query over several devices, first define what the result should mean. Do you want separate histories for each asset, or do you want measurements aligned for comparison? The answer may affect how the application structures the request and presents the returned timestamps. Avoid combining paths simply because they share a chart.

From a query result to an operational answer

Returning rows is only the first step. The client should preserve timestamps when it converts results into chart points, API responses, or exported data. Sorting and timezone presentation should be consistent with the application’s timestamp policy. If the query returns no rows, the interface should distinguish “no observations in this interval” from “the device or measurement was not found.”

For larger ranges, decide whether the user needs raw readings or a summary. A trend chart may need every point for a short period; a longer report may be better served by a time-window aggregation. Aggregation changes the question from “what values were recorded?” to “what summary describes each window?” That deserves a separate query design rather than an invisible transformation.

Conclusion

A time-range query is most useful when it expresses a concrete question. Select the device, choose the measurement, define the interval, and preserve the timestamp meaning through the client application. That gives operators and developers a clear starting point for retrieving and investigating IoT history.

Apache IoTDB is an open-source time-series database for IoT workloads. Explore the project and its current query guidance in the Apache IoTDB GitHub repository.

TimechoDB Cloud: A Simpler Way to Deploy and Use a Time-Series Database

Timecho — Tue, 20 Oct 2026 06:20:54 +0000

Industrial equipment generates data continuously. Measurements such as temperature, pressure, vibration, current, rotational speed, and equipment status are recorded over time, creating a detailed history of how machines and production systems operate.

As this industrial time-series data grows, enterprises need more than reliable storage and efficient queries. They also want a more convenient way to deploy and use a database, with less complexity in environment setup and day-to-day management.

To address this challenge, Timecho introduced TimechoDB Cloud, the cloud service offering of TimechoDB. It enables developers and enterprise teams to create and manage TimechoDB instances online, shortening the path from environment setup to data ingestion, querying, and application validation.

What Is TimechoDB Cloud?

Before looking at the service in detail, it is useful to distinguish three related—but different—names: Apache IoTDB, TimechoDB, and TimechoDB Cloud.

Apache IoTDB is an open-source, IoT-native time-series database project under the Apache Software Foundation. It provides an open-source foundation for collecting, storing, managing, and analyzing time-series data in IoT and industrial environments.

TimechoDB is Timecho’s commercial product, built on Apache IoTDB technology. Developed by members of the Apache IoTDB core team, it is designed for enterprise applications and industrial deployments.

TimechoDB Cloud is the cloud offering of TimechoDB. It brings instance creation, resource configuration, connection details, and database access into one online platform.

In short, Apache IoTDB provides the open-source technology foundation, TimechoDB brings that foundation into a commercial product for enterprise and industrial use, and TimechoDB Cloud makes TimechoDB available through a managed cloud service.

Create a TimechoDB Instance in Under 30 Seconds

The most immediate difference between a self-managed deployment and a cloud service is the setup process.

Setting up TimechoDB independently typically involves provisioning a server, installing the database, adjusting configuration, initializing the service, and—where applicable—obtaining a machine code and activating the license. TimechoDB Cloud automates these steps.

After an instance specification is selected, the platform automatically creates and initializes the instance and activates its license. Under the current product workflow, a TimechoDB instance can be created in under 30 seconds.

Once the instance is ready, its key details are available in one place: basic information, including status and resource configuration; connection endpoints, such as the REST and console URLs; and connection options, including TimechoDB CLI, JDBC, and Python.

Timecho Workbench is also accessible directly from TimechoDB Cloud. SQL can be written and executed in the workbench without setting up a separate client, making it possible to manage data and validate queries in the same environment.

This gives developers more time to focus on data models, queries, and business applications instead of database installation and environment configuration.

Multiple Architectures for Different Workloads

As a project moves from early evaluation to production use, infrastructure requirements often change as well.

A developer or technical team may need only a small environment for product evaluation and proof-of-concept work. A production workload may require higher availability, additional resources, or a multi-node architecture.

TimechoDB Cloud provides standalone, active-active, and cluster architecture options. Instance specifications can be selected according to testing or production requirements and adjusted as the application’s scale and resource needs change.

Dedicated Resources and Instance Isolation

For industrial organizations, cloud adoption is not only about convenience. Data security, resource isolation, and access boundaries are equally important.

TimechoDB Cloud is designed with instance-level resource isolation. Each cloud instance operates with dedicated CPU, memory, and storage resources, without resource sharing across different user instances.

It provides three layers of separation:

Resource isolation: CPU, memory, and storage are dedicated to the instance owner.
Network isolation: other user instances cannot access the instance's network.
Permission isolation: access is controlled at the product and account level.

These boundaries give organizations a clearer basis for assessing how a cloud database environment fits their infrastructure and data-governance requirements.

From Managing Time-Series Data to Using It

A time-series database must first handle the fundamentals: reliable storage, data management, and efficient querying. But the value of time-series data does not end once it has been stored.

In equipment operations, energy management, and industrial production, historical data can also be used to identify trends and support forward-looking analysis.

Within Timecho's DB × AI product architecture, TimechoDB Cloud can serve as the time-series data management layer. When model-based time-series analysis is needed, it can connect with TimechoAI.

The components have distinct responsibilities:

TimechoDB Cloud stores, manages, and queries operational time-series data.
TimechoAI provides model services for tasks such as time-series forecasting.
TimechoCLI connects the database, TimechoAI, and an application-layer AI agent, supporting data retrieval, SQL validation, prediction calls, and result handling.

This is more than simply placing a database alongside an AI model. Each component has a defined role: the database manages the data, the model performs forecasting, and the tool layer manages connectivity and deterministic execution.

What TimechoDB Cloud Can Help With

TimechoDB Cloud removes much of the preparation involved in self-managed deployment, making it suitable for developers and enterprise teams that need to set up a time-series data environment quickly.

1. Product Evaluation and Feature Testing
Create a TimechoDB instance quickly to explore data modeling, data ingestion, SQL querying, and other core product capabilities.

2. Time-Series Application Development and Validation
Build a time-series data environment for scenarios such as industrial equipment, energy management, and the Internet of Things. The environment can be used to validate data ingestion, storage, querying, and application-integration approaches.

3. Technology Selection and Architecture Evaluation
Select instance specifications and deployment architectures based on business requirements, then evaluate database performance under the target workload. The results can provide a practical reference for subsequent technology and architecture decisions.

Conclusion

TimechoDB Cloud is the cloud service offering of TimechoDB, designed to reduce the operational overhead of deploying and using a time-series database.

By simplifying instance provisioning and everyday access, it helps developers and enterprise teams move more efficiently from data ingestion to management, querying, and application validation. When forecasting becomes part of the workflow, TimechoDB Cloud can also connect with TimechoAI as part of a broader DB × AI architecture.

If you’re exploring or evaluating TimechoDB, visit https://db.timecho.com to create a cloud instance and experience its data management and query capabilities firsthand.

How to Design an IoT Data Pipeline for Multi-Frequency Measurements

Timecho — Tue, 13 Oct 2026 09:16:39 +0000

A connected machine may produce vibration readings many times per second, temperature readings every few seconds, power measurements every minute, and state changes only when an event occurs.

All of these signals describe the same asset. They do not need to share the same sampling rate.

For developers, the challenge is to keep each stream faithful to its source while still making cross-sensor queries possible. This article presents a practical design and test framework for that problem, using Apache IoTDB as the time-series data foundation.

1. Model observations, not empty grid cells

Start with the observation that actually occurred:

device: motor-07
measurement: temperature
event_time: 2026-10-13T09:30:05Z
value: 62.4

The important fields are the device, the measurement, the event timestamp, and the value. Metadata such as units, sensor type, location, and quality flags may also be important to the application.

Do not begin by creating a universal timeline and treating every unoccupied cell as missing. If temperature is collected every five seconds, there is no missing temperature reading at each vibration timestamp between those observations. No reading was scheduled there.

This gives us the first rule:

Preserve the native observation timeline before creating a shared analytical timeline.

2. Write down the cadence of every signal

A simple inventory exposes the shape of the workload:

Measurement	Expected cadence	Arrival pattern	Main use
vibration	high frequency	continuous, possibly buffered	inspect short events
temperature	every few seconds	mostly regular	monitor gradual change
power	every minute	regular or batch	compare operating periods
operating_state	event-driven	only on change	mark context

These values are illustrative rather than a recommended configuration. The correct frequencies come from the sensors and the engineering use case.

For each measurement, record:

the expected sampling cadence;
whether arrival can be delayed or batched;
the timestamp supplied by the source;
how long native-resolution data must remain available;
the queries that will use the signal.

This inventory prevents the fastest signal from defining the schema and retention policy for every other measurement.

3. Separate sampling time from arrival behavior

Multi-frequency data and out-of-order data are different problems, although they often appear together.

Sampling frequency describes how often a source observes a value.
Event time describes when the observation occurred.
Arrival behavior describes when and in what order the platform received it.

A gateway may collect vibration and temperature locally, lose connectivity, and upload a batch later. The measurements still belong to their original event times. If the pipeline uses arrival order as the physical timeline, historical analysis can become misleading.

Keep any ingestion timestamp or pipeline timestamp separate from the event timestamp when the application needs both. One supports operational monitoring of the data path; the other represents the measured process.

4. Store native resolution before deriving common windows

It is tempting to resample every signal during ingestion. That can simplify one dashboard, but it also commits the whole system to one analytical choice.

A safer default is:

sensor observations
        ↓
native time-series storage
        ↓
query-specific alignment or aggregation
        ↓
dashboard / investigation / model input

This structure keeps the source observations available while allowing multiple derived views.

For example:

A live dashboard might use one-minute aggregates.
A vibration investigation might retain the original high-frequency samples.
A weekly report might compare hourly summaries.
A model pipeline might use a defined resampling interval and explicit missing-value policy.

The analytical interval is part of the query or downstream transformation, not a universal property of the asset.

5. Choose alignment semantics explicitly

When two signals are compared, define what it means for their timestamps to “match.” Several approaches are possible:

aggregate observations into fixed windows;
select the most recent observation before a boundary;
use a nearest observation within an allowed tolerance;
interpolate a value according to a documented method;
keep the series separate and compare trends rather than individual points.

The right choice depends on the signal. Carrying a device state forward may be reasonable because the state remains active until it changes. Carrying a rapidly changing sensor value forward can be misleading. Interpolation may be useful for visualization but inappropriate when the application must distinguish measured values from estimates.

Every derived value should have clear semantics. If the application needs traceability, keep recorded observations distinguishable from aggregated or interpolated results.

6. Use Apache IoTDB as the time-series foundation

Apache IoTDB is an open-source, IoT-native time-series database for connected-device workloads. It supports multi-frequency and out-of-order ingestion, historical and real-time data management, timestamp alignment, aggregation, and time-series functions.

For a multi-frequency pipeline, these capabilities support a practical separation of concerns:

Devices and gateways produce observations at their own cadences.
Apache IoTDB stores the measurements with their device and time context.
Queries or downstream applications create the alignment and aggregation needed for a specific task.

Apache IoTDB does not choose the engineering meaning of an aligned value. Developers still need to define windows, tolerances, interpolation rules, and quality handling according to the application.

Exact SQL syntax and available functions can vary by release and data model, so implementation examples should be checked against the documentation for the version being evaluated.

7. Build a small validation dataset

Before testing at scale, create a dataset whose correct result is easy to inspect.

Use three signals:

temperature: one observation every 5 seconds
power:       one observation every 60 seconds
state:       event-driven changes

Add a few realistic conditions:

delay one temperature reading;
upload one short batch after a simulated reconnect;
omit a scheduled observation;
include a state transition between two power readings;
retain the expected output for each test query.

Then verify:

Native retrieval

Can each series be retrieved with its original event timestamps and values?

Windowed aggregation

Can temperature and power be summarized into a shared window without altering the stored source observations?

State context

Can the application determine which operating state applied during a selected time range?

Late data

Does a delayed reading appear in the time range where the event occurred?

Missing versus unscheduled

Can the application distinguish a missing scheduled temperature reading from the normal absence of temperature points between scheduled samples?

This small test catches semantic errors that a large throughput test can miss.

8. Review the design before production

Use this checklist before connecting a production source:

[ ] Every measurement has a defined event timestamp.
[ ] Expected sampling cadence is documented per signal.
[ ] Unscheduled timestamps are not automatically classified as missing data.
[ ] Arrival time is separated from event time where required.
[ ] Native-resolution observations remain available for the required period.
[ ] Aggregation windows match their operational questions.
[ ] Interpolated and recorded values can be distinguished when necessary.
[ ] Delayed and out-of-order data are included in validation tests.
[ ] Version-specific Apache IoTDB behavior is checked before deployment.

Conclusion

Multi-frequency telemetry is a normal property of connected systems. A pipeline becomes easier to reason about when it preserves each sensor's native observations and creates shared timelines only for defined analytical purposes.

Apache IoTDB provides an open-source time-series foundation for ingesting, storing, and analyzing data that arrives at different frequencies and sometimes out of order. The most useful evaluation is one built from your actual signal cadences, event-time rules, and query patterns.

Explore the Apache IoTDB GitHub repository and start with a small multi-frequency dataset whose expected results you can verify.

Time-Series Storage: How to Evaluate Encoding and Compression for IoT Data

Timecho — Mon, 28 Sep 2026 04:19:53 +0000

A developer-oriented guide to testing storage efficiency without losing the query and ingestion behavior that makes telemetry useful.

When an IoT deployment keeps data for months or years, storage settings become part of the application design. A database may receive millions of measurements, but the important question is what those measurements look like after they are stored: can the system retain the required history, keep accepting new data, and answer time-window queries predictably?
This is where encoding and compression matter. They are connected, but they are not interchangeable terms.

Encoding versus compression

Encoding chooses a representation for values before they are stored. Time-series data often has useful structure: timestamps follow a time axis, neighbouring values may be similar, and each measurement has a stable type and device context.

Compression then reduces redundancy in that representation. A simplified pipeline looks like this:

timestamped measurements
        -> encoding
        -> compression
        -> stored time-series blocks
        -> decode/query when read

The goal is not merely to make a file smaller. The stored representation still has to support continuous writes, historical reads, aggregation, recovery, and whatever operational processes depend on the data.

Start with the data profile

Do not select a setting from a single compression-ratio example. First describe the series you actually expect to store:

devices:              number and hierarchy
measurements:         temperature, pressure, vibration, counters, status, ...
sampling frequencies: per measurement group
arrival pattern:      steady, batched, bursty, or mixed
event-time disorder:  expected late-arrival pattern
retention:            recent and historical windows
queries:              latest values, ranges, aggregations

Different signals can behave very differently. A slowly changing temperature series may contain more repeated structure than a noisy vibration series. A counter has a different pattern again. A realistic sample should include the main types rather than replacing them with random values.

Match the method to the signal

Apache IoTDB V2.0.x provides encoding methods for different data types and patterns. Three examples make the selection logic concrete:

TS_2DIFF is suited to monotonically increasing or decreasing integer sequences.
RLE is useful when values repeat consecutively.
GORILLA is designed for nearby consecutive numeric values and is a better fit than differential or run-length approaches for some floating-point series.

Compression follows encoding and operates on the binary stream. V2.0.x supports several compression methods, including LZ4, SNAPPY, GZIP, ZSTD, and LZMA2. Treat them as candidates to test rather than a fixed best-to-worst list.

What to measure

A useful experiment changes one major storage variable at a time and records the surrounding conditions. At minimum, capture:

stored size for the same input data;
write acceptance and end-to-end availability;
CPU and memory during writes and reads;
recent-value and time-range query behavior;
aggregation behavior over longer windows;
compaction, recovery, backup, or retention effects relevant to the deployment.

Run representative queries while ingestion continues. A setting that reduces disk use but makes routine historical queries impractical may not be a good fit. Likewise, a setting that looks good in a short load may behave differently after the system has accumulated a realistic history.

A small, reproducible test plan

The following process is intentionally release-neutral. Exact configuration names and supported options should be checked in the Apache IoTDB documentation for the version being evaluated.

1. Prepare a fixed sample

Export or generate a bounded sample with known device identifiers, measurement types, event timestamps, and values. Keep the sample unchanged across runs.

2. Include realistic timing

Mix the expected sampling frequencies. If the ingestion path can receive buffered or retried records, include a controlled amount of late data while preserving event time.

3. Establish a baseline

Load the sample with the baseline configuration. Record the configuration, software version, deployment shape, hardware limits, duration, and client behavior.

4. Evaluate storage and reads together

Measure the stored footprint, then run the same latest-value, range, and aggregation queries. Repeat selected reads while new data is being written.

5. Compare one change at a time

Change one encoding or compression-related option, rerun the same workload, and compare the complete result. Avoid changing schema, batch size, retention, and storage settings in the same run unless the experiment is explicitly testing that combined design.

How Apache IoTDB fits

Apache IoTDB is an Apache open-source, IoT-native time-series database. In its Tree Model, each time series can have its own data type, encoding method, and compression method. The project supports multiple encoding methods for different data types and applies compression after encoding, providing a storage and query foundation in which those choices can be evaluated alongside ingestion and time-aware analysis.

That relationship is important for developers. Storage is not a post-processing step detached from the rest of the system. Device identity, measurement meaning, event time, late arrivals, and query windows all influence whether a storage design remains useful.

Before using a particular option, verify its exact name, default, supported data types, and version behavior in the release documentation. Then test with the workload you intend to operate.

Conclusion

Encoding and compression are valuable because time-series data contains structure that generic storage may not exploit efficiently. But storage efficiency is only one part of the result. The best configuration is the one that balances footprint, ingestion, resource use, query behavior, and operational work for a representative workload.

To learn more and try Apache IoTDB, visit the Apache IoTDB GitHub repository.

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.