TDengine

Key features

• One table per collection point, super and virtual tables. TDengine models data as one table per collection point and adds super tables and virtual tables, a design the docs say addresses high-cardinality workloads reaching billions of collection points.[1]

• Caching, stream processing, and subscription built in. Built-in caching, stream processing, and data subscription are part of the platform, which the docs say reduces extra system components and operating cost for time-series pipelines.[1]

• Cloud-native clustering and horizontal scale. The docs treat clustering as essential for growing workloads and cover cluster deployment, fault tolerance, and disaster recovery; the site positions TDengine as cloud-native for public, private, or hybrid clouds.[1][2]

• TSDB plus an industrial data platform with a free tier. TDengine TSDB is the database product while TDengine IDMP packages ingestion, storage, analytics, modeling, visualization, and AI use in one industrial platform. A free tier covers up to 5,000 tags for evaluation, PoC, or small production.[1][2]

• REST API and multi-language connectors. The developer guide covers connecting, modeling, writing, querying, caching, and subscription with sample code in multiple languages, plus a REST API and connectors reference.[1]

Who it fits

• Teams ingesting industrial sensor data. The docs state TDengine is purpose-built for IoT, connected vehicles, industrial internet, finance, and IT operations. That documented audience, not a vendor claim about your workload, is the basis for this fit.[1]

• IT operations and monitoring workloads. IT operations is a named target scenario with caching and subscription primitives that suit metrics pipelines. This fit is inferred from the documented scenarios, not stated by the vendor.[1]

• Teams considering a move off InfluxDB. The vendor documents a full InfluxDB migration path with a sync-before-you-decide connector, so teams already on InfluxDB can evaluate on production data. This fit follows from the documented migration support.[1]

Limits to weigh

• Paid editions gate enterprise needs. Enterprise and Cloud editions plus paid support sit above the open core, so organizations needing included support or enterprise features should budget beyond the free tier. Edition boundaries come from the pricing and OSS pages.[1][2]

• Cluster operations need administrator effort. Single-node Docker start is simple, but the operations surface (upgrades, fault tolerance, cluster maintenance, tuning) means multi-node deployments want an administrator. This difficulty reading is editorial.[1]

• SSO and offline behavior unconfirmed. Observed sources do not document single sign-on or offline and air-gapped operation, so neither is claimed here. Treat these as open questions to check in the docs or with the vendor before adopting.[1][2]

Community signals

Compatibility and deployment