Apache IoTDB

An Apache time-series database for industrial IoT that stores everything in its own open file format, TsFile, and lets you model devices as a tree of paths or as SQL tables.

What it is: Time-series databases
Type: Open source
Made by: Apache Software Foundation
License: Apache 2.0
Facts checked: 9 October 2026

What it is

IoTDB is built around devices and their measurement points: each point, such as a turbine’s wind speed, is a time series. Version 2.0 offers two ways to model them in one server. The tree model names every series by a dotted path like root.db.turbine.device1.speed, much like files in folders, which fits SCADA-style plant hierarchies. The table model, first shipped as a beta in February 2025, uses one table per device type: TAG columns identify a device, ATTRIBUTE columns describe it, and FIELD columns hold the measurements, queried with standard SQL including joins, window functions and ASOF joins. Both can live in the same instance but are isolated by default, and each client picks one with sql_dialect.

Writes go to an in-memory memtable backed by a write-ahead log and are flushed to TsFiles, a columnar format IoTDB created and that is now its own Apache project. Readings that arrive late, behind data already flushed, go to separate unsequence files that background compaction later merges into the ordered ones. A standalone server is one ConfigNode and one DataNode. The recommended cluster has three ConfigNodes, which hold metadata and partition tables and replicate them with Raft (Apache Ratis), and at least three DataNodes, which store data in regions replicated by IoTDB’s own IoTConsensus protocol by default. Series are hashed into 1,000 series slots and time is cut into seven-day partitions. Around the core sit a built-in MQTT broker, pipes that sync data from edge to cloud, and AINode, which runs forecasting models such as Timer-XL, Sundial and Chronos-2 from SQL.

IoTDB began as a research project at Tsinghua University’s School of Software and became a top-level Apache project in September 2020. Its creators founded Timecho, which sells TimechoDB, a commercial edition with extras such as dual-active deployment, audit logs and a management console. The latest release, 2.0.11 (September 2026), requires JDK 17 and adds an Edge edition that caps memory at 512 MB for about 10,000 measurements sampled once a second.

Why teams pick it

Made for messy industrial data: more than 1,000 series per machine, high sampling rates, and late readings that go to separate files instead of slowing the ordered write path
Data sits in an open file format: TsFiles written by an edge device or a Python script load with one LOAD statement or by dropping them into a watched folder
One code base from edge to cluster: a standalone 1C1D server, a 3C3D cluster with Raft-replicated metadata, and since 2.0.11 an Edge edition for 512 MB devices
Clustering and replication are in the free Apache 2.0 build, alongside a built-in MQTT broker and in-database forecasting with AINode

Watch out for

Two models mean two dialects: tree and table data are isolated by default, pipes and plugins differ per model, the CLI starts in the tree model, and tree-to-table views (since 2.0.5) are read-only
The table model is young: beta in February 2025 and declared official in 2.0.4 (July 2025), and pipes can’t sync data between 1.x and 2.x clusters, so upgrades are migrations
Some operational features are commercial: dual-active deployment, audit logs, the Workbench console and cluster management tools come with Timecho’s TimechoDB, and community support has no service levels
Floats stored with RLE or TS_2DIFF encoding keep only two decimal places by default; use GORILLA for values that need full precision
Runs on the JVM, and from 2.0.11 needs JDK 17, which matters on small edge hardware

The Apache IoTDB family

1 technologies built from or on Apache IoTDB

Distributions

TimechoDBCommercialThe commercial edition of Apache IoTDB from the company its creators founded: the same engine plus dual-active pairs, one-way data-diode sync, a Workbench console and vendor support, licensed per machine with activation codes.

Alternatives

What all time-series databases have in common →

Amazon TimestreamAWSAWS’s time-series databases: a serverless engine now closed to new customers, and managed InfluxDB 2 and 3.ArcOpen sourceA young single-binary time-series database in Go that writes incoming data as Parquet files and queries them with DuckDB SQL.

ArcticDBCommercialMan Group’s serverless DataFrame database: a Python library with a C++ engine that stores versioned pandas DataFrames directly in S3, Azure Blob Storage or local LMDB.

GreptimeDBOpen sourceA Rust database that stores metrics, logs and traces as tables on object storage, queried with SQL or PromQL.

InfluxDBOpen sourceThe best-known time-series database, fed by line protocol and Telegraf; now in its third generation, a Rust rewrite that keeps data as Parquet files on object storage.

kdb+CommercialA columnar time-series database that is also an interpreter for q, an array language, used for market data across trading and risk.

QuestDBOpen sourceA columnar time-series database in Java, C++ and Rust that ingests millions of rows a second and answers time-series SQL, with old partitions kept as Parquet.

TDengineOpen sourceA clustered time-series database for IoT and industrial data that gives every device its own table, grouped under “supertables” with tags.

TimescaleDBOpen sourceA PostgreSQL extension that turns ordinary tables into time-partitioned, compressed time-series tables.

Workers Analytics EngineCommercialCloudflare’s time-series analytics store for Workers: a non-blocking `writeDataPoint()` call to record events with unlimited cardinality, adaptive sampling to keep it cheap, and a SQL API to query them.

How it fits with other technologies

What Apache IoTDB uses

A table per device type, hourly averages, the latest value, and a TsFile import (run on the 2.0.11 Docker image) · sql

/* start-cli.sh -sql_dialect table   (the CLI starts in the tree model otherwise) */
CREATE DATABASE wind;
USE wind;

/* one table per device type: TAG columns identify a turbine,
   ATTRIBUTE columns describe it, FIELD columns hold the measurements */
CREATE TABLE turbine (
  farm       STRING TAG,
  turbine_id STRING TAG,
  model      STRING ATTRIBUTE,
  wind_speed DOUBLE FIELD,
  power_kw   DOUBLE FIELD
) WITH (TTL=31536000000);   /* keep one year, in milliseconds */

INSERT INTO turbine (time, farm, turbine_id, model, wind_speed, power_kw) VALUES
  ('2026-10-09T10:00:00Z', 'north', 't1', 'V150', 7.5, 1510.0),
  ('2026-10-09T10:20:00Z', 'north', 't1', 'V150', 8.1, 1720.0),
  ('2026-10-09T10:40:00Z', 'north', 't1', 'V150', 9.0, 2010.0),
  ('2026-10-09T10:00:00Z', 'north', 't2', 'V150', 6.9, 1380.0),
  ('2026-10-09T10:40:00Z', 'north', 't2', 'V150', 7.4, 1490.0);

/* hourly average per turbine: t1 1746.67, t2 1435.0 */
SELECT date_bin(1h, time) AS hour, turbine_id, avg(power_kw) AS avg_kw
FROM turbine WHERE farm = 'north'
GROUP BY 1, turbine_id ORDER BY turbine_id;

/* newest reading per turbine: t1 2010.0, t2 1490.0 */
SELECT turbine_id, last_by(power_kw, time) AS latest_kw
FROM turbine GROUP BY turbine_id ORDER BY turbine_id;

/* import a TsFile written elsewhere, e.g. by the Python tsfile library,
   the count comes back as 4 */
LOAD '/tmp/turbines.tsfile' WITH ('database-name'='imported', 'on-success'='none');
SELECT count(*) FROM imported.turbine;

Tree model or table model?#

IoTDB 2.x runs both models in one instance. The project’s own comparison, plus how each names data.

	Tree model	Table model
How a series is named	A dotted path under `root`, e.g. `root.db.turbine.device1.metric1`; the second-to-last level is the device	A row in a table per device type: `TAG` columns identify the device, `FIELD` columns hold the values
Suits	Monitoring and point management, e.g. DCS and SCADA	Device management, analysis, and migrating from other databases
Schema	Flexible, like a file system: add or drop branches freely	A template per device type, which helps data governance
Querying	Read and write by path, with wildcards	Standard SQL with joins, window functions, CTEs and `ASOF` joins
Choose it with	`start-cli.sh` (the default) or `SET SQL_DIALECT=TREE`	`start-cli.sh -sql_dialect table`, `SET SQL_DIALECT=TABLE`, or `sql_dialect=table` in the JDBC URL

The docs rate performance as similar for both. Since 2.0.5 a read-only table view can be defined over tree data, so devices written by path can be analysed with SQL.

See it in a real stack

No architecture uses Apache IoTDB yet. Drop it into the playground and wire it up yourself.Open playground →

Where it came from2018–2026

Industrial equipment produces time series that monitoring databases weren’t built for. The IoTDB proposal of 2018 listed the gaps: a turbine engine can report 1,000 points a second and an excavator more than 1,000 series, devices often send over UDP or buffer data during network drops so readings arrive out of order, and manufacturers keep history for the life of a machine. Gorilla and InfluxDB were aimed at data centre metrics, OpenTSDB and KairosDB sat on HBase and Cassandra, and analysing data in Spark or Hadoop meant exporting a second copy.

About two dozen students and teachers at Tsinghua University built IoTDB, with funding from the National Natural Science Foundation of China and sponsors such as Lenovo and K2Data. Its file format, TsFile, was already open source on GitHub; the database was still private. By the time it entered the Apache Incubator in November 2018 it ran in a State Grid Corporation of China staging environment with about 3 million series. The first Apache release, 0.8.0-incubating, came in August 2019, and IoTDB graduated to a top-level project in September 2020.

Version 1.0 in December 2022 brought a distributed, highly available architecture of ConfigNodes and DataNodes with a choice of consensus protocols. That June the creators’ company, Timecho, had raised more than $10 million in a round led by Sequoia China. In November 2023 TsFile left to become its own Apache project, and the 2.0 line added a relational table model next to the original tree, plus AINode for forecasting with time-series foundation models.

Why it’s built this way

A new columnar file format instead of HBase, Cassandra or Parquet: Sensors on one device rarely sample at the same instant, so TsFile stores each series with its own timestamps and no nulls, and skips Parquet’s repetition and definition levels for nested data. Spark and Hadoop could read the same files, so analysis didn’t need a second copy.
A tree of paths as the schema: Industrial assets already form hierarchies. A path such as root.China.beijing.windFarm1.windTurbine1.speed identifies a series, and a wildcard like windFarm1.*.speed selects every turbine on a farm, so grouping comes from the naming itself.
Out-of-order data kept apart: Ordered files that don’t overlap in time let a query stop scanning early. Late readings go to separate unsequence files that are merged in the background, so they don’t break that order for everyone else.
A table model alongside the tree in 2.0: Paths suit monitoring by point, but analysis across many devices of one type, and migrations from relational databases, are easier with one table per device type and standard SQL.

Timeline

2018
Enters the Apache Incubator from Tsinghua University in November
2019
First Apache release, 0.8.0-incubating, in August
2020
Graduates to a top-level Apache project in September
2022
Timecho raises over $10 million in June; 1.0 with the ConfigNode/DataNode cluster in December
2023
TsFile becomes its own Apache project in November
2025
2.0.1-beta adds the SQL table model in February
2026
2.0.11 in September requires JDK 17 and adds an Edge edition

Sources21 · facts checked 9 October 2026

Improve this page on GitHub