For IoT and industrial data platforms, this article rebuilds a reusable framework for selecting a time series database, with a focus on write throughput, storage compression, query patterns, and operational cost. Based on real-world comparisons of InfluxDB, TimescaleDB, QuestDB, and Apache IoTDB, it concludes with a decision model grounded in actual business constraints. Keywords: time series database, IoTDB, selection evaluation
Technical Specifications Snapshot
| Parameter | Details |
|---|---|
| Domain | Time series database selection, IoT data platforms |
| Candidate Products | InfluxDB, TimescaleDB, Apache IoTDB, QuestDB |
| Primary Languages | Java, Go, C++, Rust, SQL (varies by product implementation) |
| Access Protocols | SQL, Influx Line Protocol, JDBC, Prometheus, Kafka integration |
| Evaluation Baseline | Single-node write throughput of 500,000 points/sec, average latency < 10 ms, compression ratio ≥ 5x |
| Core Dependencies | Kafka, Spark, Grafana, Prometheus, PostgreSQL ecosystem |
| GitHub Stars | Not provided in the source material; omitted here to avoid inaccurate additions |
This Article Focuses on a Practical Time Series Database Evaluation Method
The most common mistake in time series database selection is not choosing the wrong product. It is evaluating brand first and scenario second. For systems such as IoT, industrial monitoring, and device telemetry, the data naturally has characteristics such as high-frequency writes, strong temporal ordering, fixed query patterns, and long retention periods.
If you continue using a general-purpose relational database or wide-table NoSQL model, the usual outcomes are unstable writes, degraded queries, inflated disk usage, and shrinking maintenance windows. In one real-world case, a team used MySQL to store device data. Once a single table grew to billions of rows, querying one day of data for a single device took several minutes.
Dedicated Time Series Databases Deliver Value Through Scenario-Specific Optimization
A time series database is not just a general database with an index on a timestamp field. It optimizes storage format, compression algorithms, hot-cold tiering, aggregation execution paths, and write engines specifically for time series workloads. It addresses the structural inefficiencies that general-purpose databases expose under dense temporal data.
AI Visual Insight: The diagram illustrates the core entry points in time series database evaluation, typically including candidate products, performance metrics, storage efficiency, query patterns, and business constraints. It helps map database capabilities to a decision path based on real production scenarios.
-- Typical time series query: retrieve data by device and time range
SELECT time, temperature, humidity
FROM device_metrics
WHERE device_id = 'dev_1001' -- Filter by device
AND time >= '2026-04-01 00:00:00' -- Start time
AND time < '2026-04-02 00:00:00' -- End time
ORDER BY time; -- Return results sorted by timeThis type of query shows that the primary battleground for time series systems is not complex transactions. It is efficient processing of continuous data within time windows.
The Evaluation Framework Must Come Before Product Comparisons
Before running any benchmark, define a consistent evaluation framework. This matters more than testing products immediately. Without a common standard, every database can win by showcasing its strongest metric in isolation.
This article identifies five critical dimensions: write performance, storage cost, query capability, ecosystem and integration, and operational complexity. Together, they cover the main risks from proof of concept through production deployment.
Write Performance Determines Peak System Capacity
IoT scenarios usually involve massive numbers of devices reporting concurrently. In that context, throughput ceilings, tail latency, and write stability matter more than individual query speed. In practice, the baseline is at least 500,000 points per second on a single node with average latency below 10 ms.
Storage Cost Continuously Consumes Budget
Once time series data must be retained for three to five years, compression is no longer a nice-to-have. It becomes a hard budget constraint. For the same one billion data points, final disk usage can vary by multiples across products.
Query Capability Must Be Evaluated by Typical Patterns, Not Feature Lists
Most high-frequency time series queries fall into only three categories: latest-point lookups, time-range queries, and periodic aggregation queries. The product that optimizes these three patterns consistently is the one that is more likely to succeed in production.
# Pseudocode: benchmark three core query patterns with a unified method
queries = ["latest", "range", "aggregate"]
for q in queries:
result = run_benchmark(q) # Run the benchmark for the specified query
print(q, result.latency) # Output the query latency metricThis code establishes a consistent query baseline and prevents each product from benchmarking different SQL statements or different datasets.
The Capability Boundaries of Mainstream Candidates Are Clear
InfluxDB stands out for its mature ecosystem and is particularly well suited to monitoring, observability, and dashboard pipelines. The TICK stack reduces the integration cost from ingestion to visualization. However, the open source edition has limited clustering capabilities, and its compression is not in the top tier.
TimescaleDB’s biggest advantage is PostgreSQL compatibility. If your team already has mature SQL workflows, JDBC integrations, and operational experience with PostgreSQL, TimescaleDB has the lowest migration friction. However, its architecture still extends a relational core, which makes it less competitive in extreme write-throughput and compression-heavy scenarios.
Apache IoTDB Aligns More Closely with Industrial and IoT Workloads
Apache IoTDB is the final choice in this article. It is designed specifically for device data, edge-cloud collaboration, and ultra-long retention scenarios. In the original implementation, 20 TB of raw data compressed down to about 2 TB, while three standard servers sustained 15 million points per second on the write path.
In addition to compression and ingest performance, IoTDB’s SQL-like syntax lowers the learning curve. Its Prometheus metrics interface and Grafana integration also make it easier to fit into existing monitoring systems. For projects that emphasize domestic technology adoption, sovereignty, or stronger controllability, this is an additional advantage.
QuestDB Fits New Projects That Prioritize High Performance and Fast Experimentation
QuestDB is highly competitive in single-node performance and SQL support, especially for streaming ingest scenarios. However, its ecosystem depth and cluster licensing strategy require more careful evaluation before large-scale enterprise adoption.
# Example: start IoTDB in standalone mode
cd apache-iotdb
./start-server.sh # Start the server processThis command reflects IoTDB’s low barrier to initial deployment, which helps teams complete a proof of concept quickly.
IoTDB Was the Final Choice Because It Matched the Business Constraints Best
There is no absolute winner in database selection. There is only the product that best fits the current business constraints. In this case, the team had five hard requirements: support for millions of connected devices, tens of millions of points written at scale, more than five years of historical retention, queries dominated by range scans and aggregations, and synchronization requirements across edge nodes.
Under these conditions, IoTDB’s strengths created a compound effect. High compression directly reduced long-term storage cost, high write throughput absorbed traffic spikes, edge-cloud coordination reduced the need to build custom synchronization pipelines, and its domestic technology profile supported compliance and controllability requirements.
IoTDB Is Still Not a General-Purpose Database Replacement
If your workload requires strong transactions, complex joins, or flexible cross-domain analytics, you should not treat IoTDB as an all-in-one database. A more practical architecture is to use IoTDB as the online primary store for time series data, then synchronize selected data into an OLAP engine or data warehouse for deeper analysis.
-- Aggregate device metrics by hour
SELECT DATE_BIN(1h, time) AS win, AVG(temperature) AS avg_temp
FROM device_metrics
WHERE time >= '2026-04-01 00:00:00'
GROUP BY win -- Aggregate by time window
ORDER BY win;This type of aggregation query is exactly the execution path a time series database should optimize, rather than complex multi-table joins.
Deployment Experience and Case Data Show Production Feasibility
Based on implementation feedback, IoTDB deployment is relatively straightforward: download, extract, update the configuration, and start the service. A three-node distributed cluster can be set up in a short time, and the official upgrade path is reasonably clear.
On the monitoring side, the Prometheus metrics interface combined with Grafana dashboards provides fairly complete visibility into write throughput, query latency, and cluster health. For long-term operations teams, this matters more than standalone benchmark numbers.
As for real-world adoption, the source material mentions large-scale deployments in CRRC Sifang, State Grid, and Baowu Steel. That indicates IoTDB has already been validated in data-intensive industries such as rail transit, power systems, and manufacturing. While data definitions vary across enterprises, this is enough to show that IoTDB is not an experimental product.
A Safer Selection Strategy Is to Run a Real POC Before Deciding
If your system prioritizes ecosystem maturity and observability tooling, evaluate InfluxDB first. If your team depends heavily on PostgreSQL skills and SQL compatibility, TimescaleDB is easier to adopt. If your main bottlenecks are write throughput, compression, and edge-cloud scenarios, IoTDB deserves focused validation. If you are building a new project and want extreme single-node performance, QuestDB is worth considering.
The final recommendation is simple: do not make this decision based on vendor marketing pages. Run a POC with your own real data, real queries, and real hardware. Spending an extra week upfront is far cheaper than spending six months migrating databases later.
FAQ
1. When do you need a dedicated time series database?
When your data has high-frequency writes, a strong time dimension, long retention periods, and queries concentrated on range retrieval and aggregations, you should prioritize a time series database instead of continuing to push a relational database beyond its design limits.
2. What scenarios is IoTDB best suited for?
It is best suited for IoT, industrial internet, energy monitoring, and connected vehicle scenarios where devices are dense, write volume is high, compression requirements are strict, and query patterns are relatively fixed.
3. Which metric is most often overlooked during database selection?
The most underestimated factors are long-term storage cost and operational complexity. Many products deliver impressive short-term benchmark scores, but five-year storage bills, upgrade strategy, and cluster maintenance cost are what actually determine production success.
Core Summary
This article reconstructs a practical method for selecting a time series database based on real IoT platform experience. It systematically breaks the process into five dimensions: write performance, compression ratio, query capability, ecosystem integration, and operational complexity. It also compares InfluxDB, TimescaleDB, Apache IoTDB, and QuestDB side by side, then explains why IoTDB was chosen and how to validate that decision in practice.