General-purpose relational databases often face three bottlenecks when handling time-series data: high random-write overhead from B+Tree indexes, low compression ratios with row-based storage, and poor full-table scan efficiency. TDengine was redesigned end-to-end, from the data model to the storage engine. Its core advantages: one table per data collection point eliminates write hotspots; Columnar Storage plus LSM Tree turns writes into sequential appends; multi-level cache coordination accelerates reads; and a six-layer query filter prunes irrelevant data layer by layer.
Supertable and Subtable model
Each collection point maps to an independent Subtable. Subtables share column definitions through a Supertable but have independent Tags. Three key advantages: zero index overhead on writes, precise query targeting, and natural partition isolation that eliminates lock contention.
Columnar Storage and LSM Tree
Each column is stored independently, enabling higher compression rates and faster aggregation queries. Through Delta Encoding and specialized compression algorithms, storage space can be reduced to 10% to 20% of the original data. The LSM Tree converts random writes into sequential appends. The write path: Client to WAL sequential write to MemTable to flush to multi-level file Compaction.
Multi-level caching
The write cache (MemTable) accumulates data in batches before performing sequential disk flushes. The read cache (Last/Cache) accelerates repeated queries. The metadata cache avoids frequent disk access.
Batch writing inserts multiple rows in a single SQL statement, reducing network overhead. Schemaless writing allows applications to send data in JSON format; TDengine automatically parses it and creates tables.
Six-Layer Query Filtering
The layers are: connection layer, syntax parsing layer, query planning layer (Tag index locates Subtables), vnode layer, storage layer (time index skips irrelevant data blocks), and intra-block filtering. Tags and time-series data are stored separately, so Tag filtering completes entirely on the Tag index, improving query efficiency by several orders of magnitude.
Tuning Recommendations
- buffer: Write cache size per vnode. A value of 512 MB is recommended.
- vgroups: Align with a multiple of the dnode count. Each vgroup should manage 1,000 to 5,000 Subtables.
- cachemodel: Choose from four modes: none, last, last_row, or both.
Benchmark Results
Test scenario: 10 billion data collection points, 100 nodes, 1 million writes per second. Results: TDengine write throughput of 1 million points per second per node (vs. 150,000 to 300,000 for general-purpose databases), disk usage of 12% (vs. 25% to 40%), time-range queries under 50 ms, aggregations under 200 ms, and Tag filtering under 10 ms. In this benchmark, the overall performance advantage exceeds 10x.
Summary
The performance advantage comes from full-chain coordinated design, spanning the data model, storage engine, cache system, and query executor. Properly configuring buffer, vgroups, and cachemodel can expose additional performance headroom.
