TDengine: a C time-series database for industrial IoT, not a general TSDB

What the high-cardinality claim actually commits the project to

The opening of the README states the problem plainly: real-time ingestion, processing and analysis of terabyte and even petabyte scale data per day, generated by billions of sensors and data collectors. The listed advantages then narrow in on one specific technical bet, which is high cardinality. The project claims to be the only time-series database to solve the high-cardinality issue while still holding ingestion, query and compression performance.

That claim is the architecture in one sentence. Most time-series stores fall over when the number of distinct series grows into the billions, because per-series metadata overhead dominates. A design that genuinely handles that regime is not interchangeable with a store that assumes thousands of series, and it is worth treating the difference as the reason to pick this project over a general-purpose option.

The second advantage listed is architectural rather than a benchmark: built-in caching, stream processing, data subscription and AI agent features. Stream processing inside the database is the decision with the longest reach, because it means windowed aggregation happens where the data lands rather than in a separate stream processor. The README also names super tables, partitioning data by time interval, pre-computation and compute-storage separation as the pieces that make analytics cheap.

Read the advantage list with some scepticism. Phrases like simplified solution and ease of use are the vendor's own framing, and the links behind each bullet go to tdengine.com rather than to documentation you can evaluate. The technical claims are specific enough to be testable, which is the better filter.

Super tables, tags and the data model behind the IoT focus

Two release entries make the data model concrete. The 3.4.0.9 notes add support for table name templates using expressions, batch modification of child table tag values, and virtual table import and export through `taosdump`. The 3.4.1.6 notes add behaviour in taos-explorer where, when a supertable data column is moved to the tag column, the default empty tag column is removed automatically.

Those two sentences describe the model better than a marketing paragraph could. A super table defines a schema once; each device or asset gets a child table that inherits it; tags are the per-child metadata, things like a serial number or a site name, and columns are the measurements that change over time. Data is written to child tables and queried across them through the parent. The consequence is a schema model that maps directly onto a fleet of similar machines, and a poor fit when your entities do not share a shape.

The optimization described in 3.4.0.9 is worth noting for capacity planning: the notes say the impact of frequent child table tag modifications on data writing is optimized for when child tables of a super table have subscriptions. That is a specific acknowledgement that tag writes and subscriptions interact, which is the sort of detail you only learn from a system that has been in production long enough to be surprised.

Virtual tables are the other addition worth understanding. Support for importing and exporting virtual tables, plus improved performance of virtual table queries on the `tbname` column, suggests virtual tables are becoming a first-class way to present data rather than an internal detail.

A contributor build path, not a user install guide

The README is explicit that its quick guide is for developers who want to contribute, build, release and test TDengine themselves. It offers four paths and hands every one of them to the documentation site: install via container, installation package, Kubernetes, or use the fully managed TDengine Cloud without installing anything.

What the repository gives a builder is a C codebase with a CMake build system, a Conan dependency manager and build entry points at the root:

./build.sh

The tree also has `build.bat` for Windows, `CMakeLists.txt` at the root, a `conanfile.py` alongside a `conan/` directory for dependency resolution, and a `deps/` directory. `contrib/` holds packaging scripts, `packaging/` holds distribution artefacts, and `utils/` holds helper tooling. `test/` is the test tree and `tools/` holds the component tooling, including the TDgpt agent that the README describes separately with its own README under `tools/tdgpt/`.

So the split is: the repository is the buildable source of a database written in C, and the user-facing instructions live at docs.tdengine.com. That is a reasonable division, but it means the README gives you no package names, no version numbers and no configuration keys. If you are evaluating this project, the documentation site and the release artefacts are where the operational detail lives.

What the recent releases reveal about where the product is heading

Three releases between March and April 2026 give a clear picture. ver-3.4.0.9 on 2026-03-02 adds token support for subscription in `taosAdapter`, taosdump support for virtual tables, table name template expressions and a large batch of Explorer UI work. ver-3.4.1.0 on 2026-04-01 is the substantial one: an MCP server for TDengine TSDB, external window queries where a subquery explicitly specifies a time range, uncorrelated scalar subqueries, the ANY, SOME, ALL, EXISTS and NOT EXISTS operators, batch modification of child table tag values, and stream scheduling by natural week, month, quarter and year dimensions.

An MCP server for the database is the headline item, and it connects to a shift visible in the related queries people type about this project: TDengine versus InfluxDB, TDengine versus TimescaleDB, TDengine Client, TDengine Cloud, TDengine install, and what TDengine IDMP is. A database competing for both human SQL clients and agent-driven access is a different posture from the one it had a few years ago.

The SQL additions are the quiet story. External window queries for cross-event correlation, window reuse and hierarchical filtering, plus uncorrelated scalar subqueries and the ANY and EXISTS families, move the dialect closer to what a general SQL engine would accept. Someone porting analytical SQL will hit fewer walls. ver-3.4.1.6 on 2026-04-30 continues with cross-origin security hardening in Explorer, an XNODE management page, taos-ws-py SQLAlchemy compatibility improvements and taosX task and connection import and export. The last push to the repository was 2026-09-17.

AGPL-3.0, an active component ecosystem, and the wrong-tool cases

The licence is AGPL-3.0, and the README says the core modules including the cluster feature and the AI agent are available under open source licences. That framing matters in one specific way: if you modify TDengine and offer it to users over a network, the AGPL's network clause is the part that requires reading by a lawyer rather than by an engineer. Nothing here is legal advice, but the practical trigger is a modified server offered to third parties, and that is worth settling before the code rather than after.

Where TDengine is the wrong tool is more concrete than where it is right. It is a TSDB, not a relational database, so joins across large tables with varied shapes are not the use case the design serves. There is no text search story in the README. There is no multi-document model, and nothing suggests a queue or a stream of unstructured events. If your data is logs with free text, or documents, or an inventory that changes shape per row, a relational database or a document store is the shorter path.

The competition framing also deserves a hard look. The project's own comparison pages are written by the project. InfluxDB and TimescaleDB are the two names people actually search for alongside TDengine, and they differ in kind rather than in benchmark score: InfluxDB's line and Flux or SQL modelling differs from a super table model built for columnar compression across billions of similar series, and TimescaleDB is a PostgreSQL extension, which means it inherits PostgreSQL's SQL surface and its operational model instead of shipping its own storage engine. Which of those is right depends on whether your series are uniform, not on which engine has the higher ingest number.

Editorial conclusion

TDengine fits sensor-shaped problems: many devices, one repeating schema, time-ordered writes and queries that aggregate over windows. It is a weaker choice for general relational work, for text search, or for anything where you need a broad query surface beyond its own dialect. Before installing anything, read the deployment pages at docs.tdengine.com rather than the README, because the README explicitly targets contributors who build, test and package from source. Two things to verify first: whether AGPL-3.0 suits your distribution, and whether your series count and retention match the high-cardinality design the project claims. For a first look, the fastest route is TDengine Cloud, which the README names as the easiest way to experience the product.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. taosdata/TDengine on GitHub