TDengine

Open-source time-series database for IoT and industrial data, honestly reviewed. Not a general-purpose tool. Probably not for you — unless you’re drowning in sensor data.

TL;DR

• What it is: Open-source (AGPL-3.0) time-series database built specifically for IoT and industrial telemetry — think a modern replacement for OSIsoft PI System, not a replacement for PostgreSQL [5].
• Who it’s for: Engineering and operations teams at industrial companies, energy firms, and manufacturers ingesting high-volume sensor data at scale. Not for non-technical founders building SaaS apps [2][5].
• Cost savings: The OSS core is free. Enterprise historian licenses start around $5,625/year for 5,000 tags, scaling to $68,750/year for 500,000 tags. PI System licenses routinely run six figures. That gap is the pitch [2].
• Key strength: Performance — benchmarks show TDengine ingests data 1.5x–6.7x faster than TimescaleDB and uses 26.9x less storage in large scenarios, while offering built-in stream processing and message queuing that would otherwise require separate infrastructure [1][5].
• Key weakness: AGPL-3.0 license (not MIT — if you embed it in a commercial product, talk to a lawyer), a narrower ecosystem than InfluxDB, and an enterprise pricing model that requires direct sales contact for anything serious [2][3].

---

What is TDengine

TDengine is a time-series database designed from the ground up for one thing: storing and querying massive volumes of time-stamped data from sensors, devices, and industrial equipment. It was created by TAOS Data in 2017 and sits at 24,776 GitHub stars. The company has recently repositioned it under the “AI-Powered Data Historian” label — a deliberate shot at legacy industrial historians like OSIsoft PI System — but the core product is a high-performance TSDB [5].

The architecture makes one unusual design choice that explains most of its performance characteristics: the supertable model. Instead of throwing all sensor readings into one massive table with device IDs as columns, TDengine treats each device or sensor as an independent table under a shared schema (the supertable). This eliminates write contention between devices, enables per-device queries without full-table scans, and makes columnar compression dramatically more effective because data from the same sensor is physically co-located [5].

Beyond storage, TDengine ships with built-in stream processing, a message queue, data caching, and native MQTT and Kafka integration. The practical effect is that a TDengine deployment can often replace a stack of four or five separate services — database, Kafka, Redis, a stream processor, and a message broker — with a single system [5]. Whether that consolidation is a feature or a liability depends on your team’s existing expertise.

The company reports 800,000+ instances worldwide, 1,000+ industrial customers, and a largest production deployment managing 50 million tags continuously for over three years [website]. It is SOC 2 Type II and ISO 27001 certified, which matters to industrial buyers more than to most developers [website].

---

Why people choose it

The reviews paint a consistent picture: TDengine gets chosen when engineers hit a wall with general-purpose databases on sensor workloads, and its closest competitors are InfluxDB, TimescaleDB, and VictoriaMetrics — not MongoDB or PostgreSQL.

Versus TimescaleDB. TDengine’s own benchmark (using the open-source TSBS framework) shows it writing data 1.5x–6.7x faster than TimescaleDB across scenarios, querying 1.2x–24.6x faster in a 4,000-device test, and using as much as 26.9x less storage in the 10-million-device scenario [1]. TimescaleDB’s advantage is that it runs on PostgreSQL — you already know SQL, your existing tooling integrates, and the ecosystem is mature. TDengine’s advantage is raw efficiency when data volume is the primary constraint [1].

Versus VictoriaMetrics. The InfluxData comparison [3] frames this as AGPL vs. Apache 2.0, and monolithic-all-in-one vs. lightweight-and-composable. VictoriaMetrics is faster to get running and has a permissive license. TDengine has the broader built-in feature set and SQL querying without plugins. Teams that want to build a monitoring stack quickly often pick VictoriaMetrics; teams replacing an industrial historian that needs retention policies, downsampling, and asset modeling lean toward TDengine [3].

Versus InfluxDB. InfluxDB (particularly InfluxDB 3.x) has a much larger ecosystem, more integrations, a mature cloud offering, and an established community. TDengine’s argument is performance at scale and the supertable model’s efficiency for device-centric data. The FitGap review [2] notes that TDengine’s SQL compatibility reduces learning curve compared to InfluxDB’s InfluxQL/Flux query language — a real friction point for engineering teams whose members know SQL but not specialized time-series query languages.

The industrial angle. The most interesting positioning is what TDengine is doing on the enterprise side: marketing directly to OT (operational technology) teams who are stuck on PI System. PI System licenses are notoriously expensive, tied to proprietary protocols, and difficult to migrate away from. TDengine’s website leads with this comparison — “roughly one-third the cost of traditional systems like PI System” — and their case studies include a steel manufacturer achieving 250,000 writes per second and a cigarette factory covering 40,000+ monitoring points [website]. For a buyer in that category, the comparison to InfluxDB is less interesting than the comparison to what they’re currently paying OSIsoft.

---

Features

Core time-series engine:

• Supertable model: each device as its own table under a shared schema [5]
• Columnar storage with 10x+ compression ratios vs. general-purpose databases [5]
• SQL-compatible query language — standard SQL with time-series extensions [1][3]
• Time-windowed aggregations, downsampling, and continuous aggregation patterns [2]
• Retention policies and data lifecycle management [2]
• Zero-copy write path and async batch insertions optimized for NVMe/SSD [5]

Built-in services (no external tools required):

• Stream processing for real-time computation over incoming data [5]
• Native message queue with MQTT and Kafka integration [5]
• Data caching layer [5]
• Native clustering, horizontal scalability, and data replication for HA [5]

Ecosystem integrations:

• Works with Grafana and Telegraf natively [5]
• SQL compatibility means standard BI tools can connect via JDBC/ODBC
• Kubernetes deployment via Helm; Docker support [5][website]
• Multi-platform: Linux, macOS, Windows [1]

AI and analytics (newer, more marketing than product so far):

• Anomaly detection and forecasting via AI/ML features [website]
• “TDgpt” for natural-language queries over industrial data [website]
• LLM-driven panel creation in their historian product [website]
• The AI features are real but nascent — the core value is still the TSDB engine

---

Pricing: SaaS vs self-hosted math

This is where TDengine gets complicated because there are effectively three products at different price points.

TDengine OSS (free, AGPL-3.0): The open-source core — the TSDB engine, SQL querying, clustering, stream processing. Free to download and run. This is what the GitHub stars are for. The AGPL-3.0 license means if you build a product on top of it and distribute it, you may need to open-source your application code. For internal tooling, it’s a non-issue. For SaaS founders, consult a lawyer before embedding it.

TDengine TSDB — Self-Hosted (Annual License): This is the paid enterprise tier, priced by number of tags (monitoring points). Per FitGap’s pricing data [2]:

Tags	Annual License
5,000	$5,625
10,000	$9,687
25,000	$15,000
50,000	$19,375
100,000	$28,750
500,000	$68,750

FitGap lists the entry price as “$609 per month” ($7,308/year equivalent), suggesting there’s a minimum closer to the 5,000-tag tier [2]. Perpetual license pricing also exists, structure not publicly detailed.

TDengine Cloud (fully managed): Custom pricing, contact sales. No public tier sheet.

Comparison with cloud alternatives:

InfluxDB Cloud Serverless runs at roughly $0.002–0.008 per data point written depending on tier. At 1 million writes per day (30M/month) you’re looking at $60–$240/month. For an IoT operation at that scale, TDengine self-hosted on a decent server ($100–200/month of hardware) quickly wins on cost, and the performance advantage compounds.

PI System for comparison: enterprise contracts typically range from $50,000 to $500,000+ annually depending on tag count and features — the comparison TDengine is leaning into [website]. If you’re currently on PI System with 50,000 tags, TDengine’s $19,375/year license is an obvious conversation starter.

For a non-industrial SaaS founder with no sensor data: this math is irrelevant to you, and TDengine is probably the wrong tool.

---

Deployment reality check

The GitHub README’s install path is building from source or using pre-built packages (apt, brew, Docker). The simplyblock review [5] notes it’s container-native with Helm support for Kubernetes. The multi-platform builds (Linux, macOS, Windows) are confirmed [1].

What you need to run it:

• A Linux server with sufficient RAM — the OSS version runs on modest hardware for small workloads, but high-ingest production deployments need proper capacity planning [2]
• Docker or a native package install for single-node; Helm for Kubernetes clusters
• Grafana (separate install) if you want dashboards — TDengine doesn’t include a built-in visualization layer in the OSS edition
• Telegraf or a native connector for your data sources

What can go sideways:

FitGap [2] flags that “running large clusters for high availability and high ingest can introduce operational considerations such as capacity planning, partitioning strategy, and backup/restore procedures.” This is a diplomatic way of saying: schema design and time-based sharding decisions significantly affect performance, and getting this wrong in production is painful.

The supertable model is powerful but requires thinking differently about your data model upfront. A team that treats TDengine like a general-purpose relational database will have a bad time.

Ecosystem gaps are real [2]: “compared with more established monitoring and historian ecosystems, integration breadth can be uneven across third-party tools, connectors, and managed-service options. Teams may need to validate compatibility with their specific collectors, ETL/ELT tools, and BI platforms.” This is a genuine limitation compared to InfluxDB’s connector catalog.

For the industrial historian use case specifically, replacing PI System means also replacing its ecosystem of adapters for OPC-UA, OPC-DA, Modbus, and hundreds of industrial protocols. TDengine supports this via Kepware and similar industrial middleware (shown in their demos), but the setup requires actual engineering work.

Realistic deployment estimate: a technical team can get TDengine running for a pilot workload in an afternoon. A production deployment with HA clustering, proper schema design, and integration with an existing industrial data stack is a weeks-long project requiring people who understand both TDengine’s architecture and the specific industrial protocols involved.

---

Pros and Cons

Pros

• Exceptional write performance. Benchmarks against TimescaleDB show 1.5x–6.7x faster ingestion and up to 26.9x better storage efficiency at scale [1][5]. This is not marketing — it’s from the TSBS framework, which is standard across the TSDB industry.
• All-in-one reduces stack complexity. Built-in stream processing, message queuing, and caching means fewer services to operate. One system instead of Kafka + Redis + a separate stream processor [5].
• SQL compatibility. No proprietary query language to learn — your engineers already know how to write window functions and aggregations [1][3].
• Supertable model is genuinely clever. Per-device table architecture is the right data model for IoT workloads and it shows in the benchmark numbers [5].
• Grafana and Telegraf integration means you can use tooling your team already knows [5].
• SOC 2 Type II + ISO 27001 for teams selling into regulated industrial markets [website].
• Serious production deployments. 50 million tags in continuous operation for 3+ years is not a toy project [website].
• 800,000 instances, 1,000+ customers — the community is real and the company is generating revenue, which matters for open-source longevity [website].

Cons

• AGPL-3.0, not MIT. Using TDengine in a product you distribute commercially has license implications. VictoriaMetrics is Apache 2.0. InfluxDB has mixed licensing. If your lawyers care about this, it’s a factor [3].
• Ecosystem is thinner than InfluxDB. Fewer connectors, fewer third-party integrations, smaller community of answered Stack Overflow questions. You will hit gaps [2].
• Not for general-purpose workloads. Relational queries across non-time dimensions, complex joins, transactional writes — wrong tool. Many teams will need a separate operational database alongside it [2].
• Enterprise pricing by tags is opaque. The OSS version is free, but scaling to enterprise features requires a sales conversation. No self-serve paid tier with a clear price [2].
• Schema design matters a lot. Getting the supertable model wrong is expensive to fix in production. The learning curve is not steep but it is real [2].
• “AI-Powered” marketing is ahead of the product. The AI historian features (TDgpt, LLM-driven panels) are on the website and in the roadmap. The core value is still the raw TSDB performance. If you came for autonomous AI operations, temper expectations.
• Industrial historian positioning is niche. If you don’t know what a PI System is or why tag counts matter, TDengine is almost certainly not the right database for your problem.

---

Who should use this / who shouldn’t

Use TDengine if:

• You’re ingesting time-series data from sensors, industrial equipment, or telemetry at scale — millions of writes per day minimum.
• You’re evaluating replacements for PI System or another legacy historian and want an open-source alternative with a defensible TCO argument.
• You need built-in stream processing and don’t want to operate a separate Kafka cluster for your data pipeline.
• Your team knows SQL and doesn’t want to learn InfluxQL or Flux.
• You’re running on-premises or in a private cloud and need to keep industrial data out of third-party SaaS.

Skip it (pick InfluxDB instead) if:

• You want the largest ecosystem of connectors and the most mature cloud offering.
• You’re building an observability stack for software infrastructure (not industrial equipment) and want something that integrates easily with everything.
• Apache 2.0 licensing matters to you.

Skip it (pick VictoriaMetrics instead) if:

• You want a lightweight, fast, permissive-licensed TSDB that’s easy to operate at small-to-medium scale.
• Your primary use case is Prometheus metric storage and you want a drop-in long-term storage backend.

Skip it (pick TimescaleDB instead) if:

• Your team lives in the PostgreSQL ecosystem and you want time-series capabilities without changing databases.
• You have significant relational data alongside your time-series data and need real joins across both.

Skip it entirely if:

• You’re a non-technical founder building a web SaaS product. You don’t have sensor data and you don’t need a TSDB.
• Your time-series data volume is modest — under a few million rows. PostgreSQL with a good index handles this fine.
• You want a simple, self-serve cloud database with predictable per-query pricing.

---

Alternatives worth considering

• InfluxDB — the most established open-source TSDB, largest ecosystem, proprietary business source license on v2+/v3. Best choice if you want a managed cloud option with minimal ops overhead.
• TimescaleDB — PostgreSQL extension for time-series. Best if you’re already in the PostgreSQL world and want SQL without migrating.
• VictoriaMetrics — Apache 2.0, fast, lightweight, excellent Prometheus compatibility. Best for monitoring/observability workloads where you don’t need the full data historian feature set.
• QuestDB — newer, fast, SQL-native, targets finance and IoT. Worth evaluating if column-oriented append-only workloads dominate.
• ClickHouse — not a TSDB but handles time-series analytics at enormous scale via its columnar architecture. Better for analytics over historical data than for real-time IoT ingestion.
• OSIsoft PI System — the incumbent TDengine is positioned against. Mature, massive ecosystem of industrial connectors, six-figure licensing, deeply embedded in large industrial operations. Not going anywhere soon.
• Prometheus + Grafana — the open-source monitoring default. Prometheus is not a long-term storage solution by design, but paired with Thanos or VictoriaMetrics it handles most DevOps observability needs.

---

Bottom line

TDengine is a serious database for a specific and narrow problem: storing and querying enormous volumes of time-stamped sensor data from industrial and IoT environments. The performance benchmarks are real, the supertable architecture is well-conceived, and the value proposition against PI System is clear for anyone paying OSIsoft licensing fees. The AGPL license, thinner ecosystem, and enterprise pricing that requires a sales call are genuine trade-offs worth understanding upfront.

What TDengine is not is a general-purpose database, a developer-friendly hobby project, or the right answer for founders building standard web applications. The “AI-Powered Data Historian” rebrand is a marketing move targeting a specific enterprise buyer — industrial operations teams who want to modernize without a $200,000 software contract. If that’s you, TDengine deserves a serious evaluation. If it’s not, there are better tools with less operational complexity for your use case.

---

Sources

1. Haojun Liao, TDengine Blog — “TSDB Comparison: TimescaleDB vs. TDengine” (March 24, 2023). https://tdengine.com/tsdb-comparison-timescaledb-vs-tdengine/

2. FitGap — “TDengine reviews 2026” — pricing, feature overview, and market positioning. https://us.fitgap.com/products/015744/tdengine

3. InfluxData — “TDengine vs VictoriaMetrics: A detailed comparison” (updated March 27, 2024). https://www.influxdata.com/comparison/tdengine-vs-victoria/

4. Jeff Tao, TDengine Blog — “Is Closed-Source Software Really More Secure?” (April 8, 2024). https://tdengine.com/closed-source-security/

5. Simplyblock — “TDengine on NVMe for Real-Time Ingestion” (glossary entry). https://simplyblock.io/glossary/what-is-tdengine/

Primary sources:

• GitHub repository: https://github.com/taosdata/tdengine (24,776 stars, AGPL-3.0 license)
• Official website: https://tdengine.com
• TDengine pricing page: https://tdengine.com (historian pricing section)