Last Updated: October 2026
The comparison of InfluxDB 3 vs TimescaleDB vs ClickHouse below was written against TimescaleDB 2.17 and ClickHouse 24.x. All three projects have moved a long way since. InfluxDB 3 is now on its 3.12 line, TimescaleDB is on 2.29 and the company behind it presents itself as Tiger Data, and ClickHouse ships monthly 26.x releases with 26.8 as the current long-term support (LTS) branch. The architecture reasoning in the original still holds, but the version numbers and some feature gaps it describes are out of date.
The original article is preserved exactly as published. The section below covers what changed and what we could and could not verify. We did not re-run any benchmarks, so treat the throughput and cost figures in the original as historical.
What changed for October 2026
Here is where each engine stands, based on official release notes and docs read on 19 October 2026.
| InfluxDB 3 (Core / Enterprise) | TimescaleDB (Tiger Data) | ClickHouse | |
|---|---|---|---|
| Latest release seen | 3.12.1 (release notes page, undated entries) | 2.29.2, 18 Aug 2026 | 26.9, 21 Sep 2026 |
| Stable / LTS track | 3.11.x patched in parallel (3.11.7) | 2.29.x patches; 2.28.3 on 16 Jul 2026 | LTS 26.8 (to 27 Aug 2027) and 26.3 (to 26 Mar 2027) |
| Licensing | Core described as open source; Enterprise is a commercial superset | Apache 2 edition, or Community edition under the Tiger Data License (TSL) | Open source; we did not re-verify the licence text |
| Headline change | Distributed compaction (beta), per-database schema enforcement, GA RBAC (Enterprise) | Chunk-exclusion DML; PostgreSQL 15 dropped | Prometheus API on TimeSeries tables, ZSTD(3) default |
InfluxDB 3. The Core release notes list v3.12.1 as the newest entry, with v3.12.0 introducing faster bulk import, distributed compaction (beta), per-database schema enforcement and generally available user authentication and role-based access control in Enterprise. The notes state that Enterprise is a superset of Core, that schema enforcement (--schema-mode explicit) is Enterprise-only, and that Core remains Parquet-only, without the upgraded storage engine. The 3.12.0 notes also warn that after upgrading, 3.11.x cannot load the catalog, so back up first. Core breaking changes include a finite default for --max-concurrent-queries, a 429 response when WAL buffer limits are hit, and a move to DataFusion 52.5. The original article describes Core and Enterprise loosely; the practical split today is that features such as explicit schemas and the newer engine sit on the Enterprise side. The release notes do not name a licence for either edition, so check the repository before you rely on a specific one.
TimescaleDB and Tiger Data. The GitHub releases show 2.29.0 on 28 July 2026, 2.29.1 on 4 August (including security fixes, advisory GHSA-hcfx-29v5-2rcw) and 2.29.2 on 18 August. Release 2.29.0 supports PostgreSQL 16, 17 and 18 and removes PostgreSQL 15. It also makes DML on hypertables use chunk exclusion, taking row-exclusive locks only on affected chunks, and adds a row-retrieval path for some last-point queries on the columnstore. The docs now use the Tiger Data brand and call the hosted platform Tiger Cloud, while still naming the database TimescaleDB. Licensing is two-tier: the Apache 2 edition covers core hypertables and basic hyperfunctions, while the Community edition, under the Tiger Data License, adds the columnstore (Hypercore), continuous aggregates, retention and job policies, gap filling and SkipScan. Community can be self-hosted free but cannot be offered as a service. The original article’s “Timescale Cloud” pricing line should be read as Tiger Cloud today, and we have not re-checked prices.
ClickHouse. ClickHouse 26.9 was released on 21 September 2026. The LTS releases are 26.8 (27 August 2026, supported for a year) and 26.3; 25.8 reached end of support on 29 August 2026 per endoflife.date, so a pin on 24.x is far out of support. For time series, 26.9 adds Prometheus HTTP API endpoints (metadata, labels, label values) and SELECT support on TimeSeries tables, plus more PromQL functions. Breaking changes to check before upgrading include the analyzer no longer being disableable, the default compression moving from LZ4 to ZSTD(3), and removal of WINDOW VIEW. JSON subcolumn bracket syntax and an Iceberg v3 improvement round out the release.
What it means for IoT time-series workloads
Schema discipline is becoming a first-class feature. The original article praised InfluxDB 3 for schema-less ingest. Enterprise now offers per-database explicit schemas, which reflects what many fleets learn the hard way: a typo in a tag name silently creates a new series. If you run a mixed fleet of gateways with firmware drift, enforced schemas catch drift at the door. Core users who need that will either upgrade or validate upstream, for example in the broker or a stream processor.
Operational maturity matters more than the benchmark. InfluxDB’s recent notes are dominated by catalog, WAL and snapshot fixes, TimescaleDB’s by lock contention and compressed-data edge cases, and ClickHouse’s by a monthly cadence with two LTS lines a year. For a plant that upgrades once or twice a year, ClickHouse’s LTS policy and TimescaleDB’s PostgreSQL version alignment give the clearest upgrade calendar. TimescaleDB 2.29 dropping PostgreSQL 15 means a PG upgrade is now part of the TimescaleDB upgrade path for anyone still on 15.
Licensing is a design input, not a footnote. If you plan to offer time-series storage as a managed service to customers, the TSL restriction on TimescaleDB Community is the deciding clause, and the Apache 2 edition lacks the compression and continuous aggregates that make it competitive. For internal plant analytics the free self-hosted Community edition is usually fine.
Prometheus compatibility shifts the edge story. ClickHouse’s TimeSeries table engine with Prometheus-style endpoints makes it a more plausible long-term store behind existing Prometheus and Grafana tooling at the edge-to-cloud boundary. It does not remove the need for downsampling and retention planning at 10,000 points per second per site, and we have not benchmarked it against the other two.
What we would do. Keep the original selection logic: TimescaleDB where you want SQL joins with asset metadata, ClickHouse for wide analytical scans over long history, InfluxDB 3 for ingest-heavy, tag-flexible telemetry. Then re-test on your own data with current versions. For the ingestion side, see our time-series database internals guide, the OPC UA historian to digital twin ingestion architecture, and the brownfield Modbus to unified namespace comparison.
Not verified. Release dates for individual InfluxDB 3 versions (the page did not show them), the exact Core licence, current Tiger Cloud and InfluxDB Cloud pricing, and any fresh performance numbers.
Sources for This Refresh
- InfluxDB 3 Core release notes
- InfluxDB 3 Enterprise documentation
- TimescaleDB GitHub releases
- TimescaleDB editions (Tiger Data docs)
- Tiger Data release notes index
- ClickHouse 2026 changelog
- ClickHouse release and LTS dates (endoflife.date)
InfluxDB 3 vs TimescaleDB vs ClickHouse for IoT Time Series (2026)
You’re building a predictive maintenance system for factory equipment, ingesting sensor telemetry from 500 edge gateways at 10,000 data points per second. Your cardinality is moderate-to-high (thousands of unique metric + tag combinations), and you need sub-second query latency on 90-day rolling windows for real-time dashboards. Three databases keep surfacing in your architecture reviews: InfluxDB 3, TimescaleDB, and ClickHouse. Each promises low latency, high ingestion, and columnar compression—but their internal trade-offs are radically different.
Architecture at a glance
This post compares these three on the dimensions that matter most to IoT workloads: ingestion throughput, compression ratio, query latency on typical TSDB access patterns, operational overhead, and total cost of ownership at production scale. We’ll anchor the comparison in real InfluxDB 3 (IOx, released April 2024), TimescaleDB 2.17 (October 2024), and ClickHouse 24.x, with honest discussion of where each excels and where it stumbles. You’ll leave with a decision matrix and a framework for choosing the right engine for your architecture.
How IoT Workloads Stress Time-Series Stores Differently
Time-series databases are not created equal. A monitoring system that logs application metrics (cardinality ~hundreds) has utterly different stress patterns than an industrial IoT platform that tags every measurement by tenant, site, asset ID, and sensor model. Traditional databases optimized for analytical throughput (Snowflake, BigQuery) ingest gigabytes per second but accept 10-second latency; TSDB workloads demand sub-second ingest acknowledgment and query response within 2–3 seconds on data older than a few minutes.
IoT time-series workloads exhibit four distinct characteristics:
1. High cardinality with moderate ingestion per tag. A single metric (e.g., vibration_rms_hz) can have 50,000 distinct tag combinations (one per motor + sensor pair), but each combination arrives at modest frequency (every 10–60 seconds). This breaks row-oriented designs because inserting 50,000 unique rows per metric on every minute boundary creates index fragmentation and bloats the wal. Column-oriented stores handle this naturally by grouping by time, then by metric, then by tags.
2. Immutable writes, append-only semantics. IoT data almost never updates—once a sensor reading lands, it’s final. This lets TSDB engines skip MVCC overhead and lean on sequential compression and segment merging instead of transaction logs.
3. Time-range scans dominate query patterns. Ninety percent of IoT queries are “give me vibration data for motor X in the last 24 hours” or “compute 5-minute rolling averages across the sensor fleet for the past week.” Aggregation queries that bundle computation into the query engine (not the client) are critical; subqueries are rare. This contrasts sharply with transactional workloads where point lookups and multi-table joins are the norm.
4. Cardinality-aware compression is a must. When you have 50,000 distinct tag values for a single metric, dictionary compression of tag columns can reduce storage by 20–40x compared to repeated string storage. Generic compression (gzip, lz4) can’t compete.
Architecture Side-by-Side: InfluxDB 3, TimescaleDB, ClickHouse
Each database takes a fundamentally different approach to columnar storage and time-series optimization.
InfluxDB 3 (IOx): Columnar Parquet on Immutable Object Storage
InfluxDB 3 is a complete rewrite from InfluxDB 1.x/2.x. It abandons the proprietary TSM format and instead layers a columnar Parquet engine on top of Apache Arrow and DataFusion, with data stored as immutable Parquet files on object storage (S3, Azure Blob, or local filesystem).
Write path: Incoming data lands in an in-memory buffer (typically 1–5 GB), where it’s organized by table and time range. When the buffer reaches a threshold (or a time window closes), InfluxDB 3 flushes it as a Parquet file to object storage. The write is acknowledged before flush, so durability comes from a write-ahead log, not the Parquet file. Queries against recent data hit the hot buffer; older data is read from Parquet files via the DataFusion query engine.
Query path: DataFusion uses Parquet’s built-in metadata (min/max values, bloom filters) to prune entire files that don’t overlap the query time range. Within a file, columnar projection pushdown means reading only the columns you select (e.g., only the temperature column, not all tag columns). InfluxDB 3 supports both SQL and the legacy InfluxQL query language.
Key advantage: No cardinality limits. Parquet scales naturally with tag cardinality because columns are independent; adding a new tag doesn’t bloat row storage.
Key constraint: Object storage latency. A query on 100 parquet files means 100+ S3 API calls in the worst case. While InfluxDB 3 caches parquet metadata aggressively and uses async I/O, latency-sensitive queries on deep historical windows (e.g., 2-year time ranges) can tail at >2 seconds. Also, the write buffer sits in memory, so a node crash loses unwritten data if durability is configured loosely.
TimescaleDB: Hypertables as Transparent Partitioning
TimescaleDB is a PostgreSQL extension that adds hypertables—transparent partitioning on time + tag space dimensions. Beneath the surface, a hypertable is a set of regular PostgreSQL tables (chunks), each covering a time range (e.g., 1 week) and optionally space (tag sets). The TimescaleDB extension intercepts writes and inserts and distributes them to the right chunk.
Write path: On insert, TimescaleDB hashes the tags to determine a destination chunk, then appends the row. Multiple rows can land in the same chunk if they share the same time bucket and tag hash. Chunks are automatically created when a new time period begins.
Compression path: Chunks older than a threshold are “compressed” into columnar form. TimescaleDB groups rows by tag values (or a subset of tags) and stores each tag group as a separate columnar segment. Within a segment, each column is compressed with algorithmic codecs (PGLZ, LZ4, ZSTD). Compressed chunks see 10–40x space reduction (depending on data skew and column cardinality) and queries that scan compressed chunks are decompressed on the fly.
Query path: Queries use PostgreSQL’s planner to route to relevant chunks (pruning whole chunks based on time constraints), then execute standard SQL. Joins with other tables work naturally. Continuous aggregates (a feature added in TimescaleDB 2.0) allow creating automatic materialized views that refresh on new data—e.g., a “hourly average of temperature by sensor” table that auto-updates when new rows arrive.
Key advantage: Full SQL compatibility with PostgreSQL ecosystem. Joins, transactions, and row-level constraints work as expected. Continuous aggregates eliminate the need for a separate aggregation pipeline.
Key constraint: Chunk granularity and tag hashing determine query efficiency. If you query a narrow time range on a large tag set, TimescaleDB still reads entire chunks; it can’t prune within a chunk the way a true columnar database can. Also, the transition from hot (uncompressed) to cold (compressed) chunks creates a two-tier query experience—hot chunks are fast, compressed chunks are slower.
ClickHouse: MergeTree Family with Adaptive Indexing
ClickHouse is purpose-built for OLAP and is fundamentally different from both InfluxDB 3 and TimescaleDB. It is not an extension; it’s a standalone column-oriented DBMS. Data is stored in MergeTree tables, which are append-only column files organized by partition (typically time) and order key.
Write path: Incoming rows are collected into blocks (16,384 rows by default). When a block fills, it’s written as a “part” to disk. Each part is a self-contained set of column files. Periodically, ClickHouse merges small parts into larger ones (background process), hence the name “MergeTree”.
Indexing and pruning: Each part has a primary key (or “order key”) that determines the physical sort order of rows. Within a part, ClickHouse also builds sparse indices: the primary key index stores the value of the order key at every N rows (sparse granule), and a mark file maps granule ranges to file offsets. When a query filters on the order key, ClickHouse uses these sparse indices to skip granules that don’t overlap the query predicate.
Query path: ClickHouse uses aggressive partition and granule pruning. A query like “temperature > 75 for sensor_id = ‘S123’ in the last 24 hours” prunes partitions by date, then uses the sparse index on sensor_id to skip granules. Data is decompressed only for the relevant granules.
Variants for time-series: ClickHouse offers MergeTree variants:
– ReplicatedMergeTree: Multi-node replication for HA.
– SummingMergeTree: Automatically sums values during merge (e.g., for pre-aggregated metrics).
– AggregatingMergeTree: Uses aggregate functions during merge (e.g., for distributed avg, max).
Key advantage: Extremely fast scans over large data volumes. The sparse index and aggressive granule pruning mean you can scan weeks of data in <1 second if the query filters on the order key.
Key constraint: Not a transactional database. Deletes are asynchronous background operations; updates require reading and rewriting entire parts. Joins are expensive compared to InfluxDB 3 or TimescaleDB because ClickHouse doesn’t have a traditional query optimizer—it’s designed for analytical queries on a single large table, not schema stars. Also, the columnar storage is optimized for read throughput, not write throughput; typical ingestion rates per node are 100K–1M rows/sec (high, but lower than InfluxDB 3’s 10–100M rows/sec).
Architecture Diagram: The Three Approaches
InfluxDB 3: TimescaleDB: ClickHouse:
------------------- --------------- ---------------
Writes Writes Writes
↓ ↓ ↓
[Buffer] (Hot) [Uncompressed [MergeTree Parts]
↓ Chunk]
Flush to ↓
Parquet [Compressed [Sparse Index]
(S3/Cloud) Chunk] ↓
↓ ↓ [Granule Pruning]
[DataFusion] [Chunk Pruning] ↓
(File Pruning) (Full Chunk Read) [Column Decompression]
↓ ↓ ↓
[Column Projection] [PostgreSQL Planner] [Fast Scans]
↓ ↓
[Parquet Decompression] [Row Fetch]
↓ ↓
[Results] [Results] [Results]
See rendered diagrams arch_01.png, arch_02.png, and arch_03.png.
Decision Matrix: Ingestion, Compression, Query Latency, TCO
| Metric | InfluxDB 3 | TimescaleDB 2.17 | ClickHouse 24 |
|---|---|---|---|
| Max Ingestion Rate (single node) | 10–100M rows/sec | 100K–1M rows/sec | 100K–5M rows/sec |
| Cardinality Limit | Unlimited (millions) | High (100K+) | High (1M+) |
| Compression Ratio | 8–25x (Parquet + codec) | 10–40x (columnar chunks) | 8–25x (codec) |
| Query Latency (last 24h, tag filter) | 200–800ms | 100–500ms | 50–300ms |
| Query Latency (historical, 1 year) | 1–5s (cloud I/O) | 2–10s | 500ms–2s |
| Warm-up Time (first query cold) | 500ms–2s | 100–500ms | <100ms |
| Transactional Semantics | No | Yes (PostgreSQL) | No |
| Update/Delete Support | Rewrite part | Native | Async, expensive |
| Multi-table Joins | Limited (DataFusion) | Native (SQL) | Expensive, limited |
| Geo-distributed Writes | Multi-write, eventual consistency | Single-write, consistency | Multi-write, eventual consistency |
| Community Managed Deployment Cost (yr, 1TB/day ingest) | $50K–$150K | $30K–$80K | $40K–$120K |
| Cloud Managed (serverless) | $5K–$20K (InfluxDB Cloud) | $3K–$15K (Timescale Cloud) | $8K–$25K (ClickHouse Cloud) |
Interpretation of the matrix:
- Ingestion dominance: InfluxDB 3 can accept 10–100x more data per node than TimescaleDB or ClickHouse. If you’re pushing 1M rows/sec into a single region, InfluxDB 3 is the clear winner.
- Cardinality: All three handle millions of unique tag combinations, but InfluxDB 3 has no practical upper limit. TimescaleDB and ClickHouse scale well up to ~1M unique values per tag column; beyond that, performance degrades.
- Recent data query latency: TimescaleDB’s uncompressed chunks are fastest (100–500ms for tag-filtered queries) because they’re hot in memory. ClickHouse sparse indices give it an edge on historical scans (50–300ms even for 1-year windows).
- Historical query latency: ClickHouse wins on pure scan speed (sparse indices prune aggressively), but if you’re querying across multiple tag combinations or need arbitrary SQL, InfluxDB 3 or TimescaleDB are faster because they don’t require as much index discipline.
- Transactional semantics: Only TimescaleDB offers true ACID transactions and multi-table joins. If your architecture requires foreign key constraints or distributed transactions, TimescaleDB is your only choice.
- Operational cost: TimescaleDB Cloud is typically cheapest for small–medium workloads because it leverages PostgreSQL’s mature hosting ecosystem (shared infrastructure). InfluxDB Cloud Serverless is cheapest for bursty, high-cardinality workloads. ClickHouse Cloud has good pricing for large, predictable scans.
When Each Wins (and Loses)
InfluxDB 3 Wins When:
- Cardinality is your constraint. 500K+ unique tag combinations per metric. InfluxDB 3 is unafraid of cardinality; it stores each tag in its own column, naturally scaling.
- Ingestion rate is extreme. 10M+ rows/sec into a single system. No other TSDB handles this without clustering.
- Queries are tag-based and high-selectivity. “Give me the last 1 hour of vibration data for motor_id = ‘MTR-4521’ and site_id = ‘US-WEST-2’.” InfluxDB’s tag-based pruning and Parquet file filtering shine.
- Your cloud provider is AWS/Azure/GCP. InfluxDB 3’s tight coupling to S3/Blob is a feature, not a limitation.
InfluxDB 3 Loses When:
- You need sub-10-millisecond query latency. Object storage I/O adds tail latency. Even cached Parquet metadata lookups incur 5–10ms per file.
- Your data model requires transactions. No ACID; no row-level locking.
- You need to do complex joins. DataFusion can join across tables, but it’s not as optimized as PostgreSQL for multi-table schema-star queries.
- You’re in a low-budget indie project. InfluxDB Cloud Serverless can get expensive if you have many small queries.
TimescaleDB Wins When:
- You need full SQL and joins. Querying your time-series data alongside application tables (users, assets, locations) is seamless.
- Your workload mixes transactional and analytical. Capturing sensor writes, then querying them with JOIN to an inventory table—TimescaleDB handles both.
- You want mature tooling and ecosystem. PostgreSQL’s EXPLAIN, query logging, monitoring, and HA (pg_dump, streaming replication, citus) are rock-solid.
- Compression and cost matter more than peak ingestion. Compressed chunks squeeze storage down to 10–40x reduction; at volume, this saves millions.
- You’re on-prem or in a private data center. TimescaleDB Cloud has managed backups, but open-source TimescaleDB is trivial to deploy in any PostgreSQL environment.
TimescaleDB Loses When:
- Cardinality exceeds 100K+ unique tags per metric. Chunk hashing becomes uneven; query pruning degrades.
- Query latency on deep historical windows is critical. Compressed chunks require decompression on scan; a 3-year query can tail at 10–15 seconds.
- Ingestion rate is above 1M rows/sec. TimescaleDB’s single-writer-per-chunk design creates contention.
- You need global write distribution. No multi-master support; all writes go to a primary.
ClickHouse Wins When:
- Query latency on large scans is the bottleneck. The sparse index and granule pruning make ClickHouse unbeatable for analytical scans on 1-year data windows (50–300ms).
- Your queries are mostly filters on the order key. If you always filter by
timestampandsensor_id(or a similar prefix of the order key), ClickHouse’s sparse index does the heavy lifting. - Data volume per node is extreme (100TB+). ClickHouse’s compression and sparsity mean you can manage massive datasets on modest hardware.
- You’re building a dashboard that pre-aggregates. SummingMergeTree and AggregatingMergeTree automatically compute aggregates during merge; no separate aggregation pipeline needed.
ClickHouse Loses When:
- Writes are high-cardinality and need immediate consistency. ClickHouse is built for OLAP; 100K writes/sec per node with 50K unique sensors is uncomfortable. Also, waiting for a merge to finalize aggregates introduces latency.
- You need ACID transactions or deletes. Deletes in ClickHouse are asynchronous; if you need “delete all rows for a user” immediately, ClickHouse is a poor fit.
- Queries are unpredictable. If your users run arbitrary SQL across any columns (not just the order key), ClickHouse’s sparse index doesn’t help; you’ll do full scans.
- Your DBA team is small. ClickHouse’s sparse index and MergeTree variants require discipline; misconfiguration leads to slow queries and bloated storage.
Trade-offs and Operational Gotchas
InfluxDB 3 — Buffer durability vs. cost. The in-memory write buffer improves throughput but introduces durability risk. If you configure InfluxDB 3 to acknowledge writes before flushing to S3, a node crash loses unwritten data. Mitigate by enabling the write-ahead log (adds 10–20% overhead) or by accepting data loss within your RPO window (typically <5 seconds).
TimescaleDB — Compression tuning. Determining the right chunk compression schedule requires understanding your data churn. Compressing too early (when chunks are small) wastes I/O and CPU; compressing too late holds uncompressed data in memory. TimescaleDB’s auto-compression policy is sensible, but custom policies can squeeze an extra 20% storage savings if tuned per table.
ClickHouse — Part merging and query latency spikes. During heavy writes, ClickHouse accumulates many small parts. When the background merge process kicks in to consolidate them, it consumes I/O and CPU, which can cause query latency to spike 2–10x. Mitigation: tune the merge policy to be more aggressive (smaller parts, more frequent merges) if you value query latency over write throughput.
All three — Cardinality explosion with metadata. If you emit dimensions like hostname, pod_id, and request_path as high-cardinality tags on every metric, you can push 1M unique combinations per metric within weeks. All three databases will struggle. Solution: move low-cardinality metadata to a separate lookup table and join on query, or emit metadata as sparse fields (only when relevant, not every row).
Practical Recommendations for IoT Architects
-
Start with TimescaleDB if you have a small team (<3 people), ingestion rates below 1M rows/sec, and need to query your time-series data alongside application tables. TimescaleDB is the most “operational” of the three—it behaves like a regular PostgreSQL database, your team likely knows SQL, and deployment is straightforward.
-
Choose InfluxDB 3 if cardinality or ingestion rate is a hard constraint. If you’re ingesting data from 100K+ sensors and each sensor has 10+ dimensions, InfluxDB 3’s unlimited cardinality and massive ingestion throughput (10–100M rows/sec) are worth the operational complexity.
-
Go with ClickHouse if your IoT pipeline is mature and your access patterns are well-understood and read-heavy. ClickHouse’s sparse indices and compression are unmatched for historical analytical scans. It’s not a good fit for greenfield projects because tuning the order key and compression policy requires expertise.
-
Use a hybrid approach: Stream hot data (last 24 hours) into TimescaleDB for fast transactional queries, and archive older data to ClickHouse for historical analysis. This balances operational simplicity with analytical scalability.
Frequently Asked Questions
Q: Which is fastest for real-time dashboards (sub-second latency)?
A: TimescaleDB on uncompressed chunks, or InfluxDB 3 with a hot buffer. ClickHouse’s sparse index is fast for historical scans but less optimized for hot data because parts are constantly merging. For dashboards showing the last hour of data, expect: InfluxDB 3 (200–800ms), TimescaleDB (100–500ms), ClickHouse (300–1000ms, if recent data is fragmented across many parts).
Q: Can I switch databases later without rewriting my application?
A: Not easily. InfluxDB 3 uses InfluxQL or SQL; TimescaleDB uses PostgreSQL SQL; ClickHouse uses SQL with ClickHouse extensions. Query syntax differs enough that switching requires application changes. Plan your choice carefully.
Q: What’s the minimum ingestion rate where each becomes cost-effective?
A: TimescaleDB Cloud: 100 GB/month (~100K rows/sec with typical IoT payloads). InfluxDB Cloud: 50 GB/month. ClickHouse Cloud: 500 GB/month. Below these volumes, vanilla PostgreSQL or InfluxDB’s free tier is cheaper.
Q: How do I handle schema changes (new sensor types, new tags)?
A: InfluxDB 3 and ClickHouse handle schema-less data naturally (new columns are auto-created on write). TimescaleDB requires ALTER TABLE or schema mapping. For high-cardinality IoT, InfluxDB 3 is the easiest because it treats every tag dimension as a separate column without predeclaring the schema.
Trade-offs Summary: Decision Flowchart
Start
↓
Ingestion > 5M rows/sec?
├─ Yes → InfluxDB 3
└─ No
↓
Cardinality > 100K per metric?
├─ Yes → InfluxDB 3
└─ No
↓
Need ACID transactions or joins?
├─ Yes → TimescaleDB
└─ No
↓
Query latency on 1-year scans <500ms critical?
├─ Yes → ClickHouse
└─ No → TimescaleDB (default for simplicity)
Further Reading
For deeper dives, explore:
- TimescaleDB hypertables and compression mechanics — how chunks are partitioned and why compression is so effective.
- Time-series database internals: InfluxDB, TimescaleDB, QuestDB (2026) — deep technical walkthrough of each engine’s storage format.
- IoT protocol latency benchmarks: MQTT, CoAP, AMQP, HTTP/3 (2026) — ensure your message broker doesn’t become the bottleneck.
External references:
– InfluxDB 3.0 Official Documentation
– TimescaleDB Documentation
– ClickHouse Documentation
By Riju M P | Senior IoT Architect at iotdigitaltwinplm.com | Full bio
Schema Markup
{
"@context": "https://schema.org",
"@type": "TechArticle",
"headline": "InfluxDB 3 vs TimescaleDB vs ClickHouse for IoT Time Series (2026)",
"description": "Decision matrix comparing InfluxDB 3.0, TimescaleDB 2.17, and ClickHouse 24 for IoT time-series workloads — ingestion rates, compression, query latency, and TCO at scale.",
"image": "/wp-content/uploads/2026/04/influxdb-vs-timescaledb-vs-clickhouse-iot-hero.jpg",
"author": {
"@type": "Person",
"name": "Riju M P"
},
"publisher": {
"@type": "Organization",
"name": "iotdigitaltwinplm.com"
},
"datePublished": "2026-04-24T14:00:00+05:30",
"dateModified": "2026-04-24T14:00:00+05:30",
"mainEntityOfPage": "https://iotdigitaltwinplm.com/industrial-iot/influxdb-vs-timescaledb-vs-clickhouse-iot-time-series-2026/",
"proficiencyLevel": "Expert",
"articleBody": "..."
}
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "Which is fastest for real-time dashboards (sub-second latency)?",
"acceptedAnswer": {
"@type": "Answer",
"text": "TimescaleDB on uncompressed chunks, or InfluxDB 3 with a hot buffer. ClickHouse's sparse index is fast for historical scans but less optimized for hot data because parts are constantly merging. For dashboards showing the last hour of data, expect: InfluxDB 3 (200–800ms), TimescaleDB (100–500ms), ClickHouse (300–1000ms, if recent data is fragmented across many parts)."
}
},
{
"@type": "Question",
"name": "Can I switch databases later without rewriting my application?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Not easily. InfluxDB 3 uses InfluxQL or SQL; TimescaleDB uses PostgreSQL SQL; ClickHouse uses SQL with ClickHouse extensions. Query syntax differs enough that switching requires application changes. Plan your choice carefully."
}
},
{
"@type": "Question",
"name": "What's the minimum ingestion rate where each becomes cost-effective?",
"acceptedAnswer": {
"@type": "Answer",
"text": "TimescaleDB Cloud: 100 GB/month (~100K rows/sec with typical IoT payloads). InfluxDB Cloud: 50 GB/month. ClickHouse Cloud: 500 GB/month. Below these volumes, vanilla PostgreSQL or InfluxDB's free tier is cheaper."
}
},
{
"@type": "Question",
"name": "How do I handle schema changes (new sensor types, new tags)?",
"acceptedAnswer": {
"@type": "Answer",
"text": "InfluxDB 3 and ClickHouse handle schema-less data naturally (new columns are auto-created on write). TimescaleDB requires ALTER TABLE or schema mapping. For high-cardinality IoT, InfluxDB 3 is the easiest because it treats every tag dimension as a separate column without predeclaring the schema."
}
}
]
}
Frequently Asked Questions
What are the current versions of InfluxDB 3, TimescaleDB and ClickHouse?
As of 19 October 2026, the InfluxDB 3 Core release notes list v3.12.1 as the newest entry, with 3.12.0 as the feature release. TimescaleDB’s latest GitHub release is 2.29.2, dated 18 August 2026. ClickHouse’s latest is 26.9, released 21 September 2026, with 26.8 and 26.3 as the supported LTS branches. The original article compared InfluxDB 3 at launch, TimescaleDB 2.17 and ClickHouse 24, so all three have moved substantially since it was written.
Is TimescaleDB now called TigerData?
The company and documentation now use the Tiger Data brand, and the hosted service is Tiger Cloud. The database itself is still referred to as TimescaleDB in the docs, including the current 2.29 releases and the editions page. We did not find an official page that spells out the rename in detail, so use the Tiger Data docs as the reference, and check the GitHub repository for the extension itself. Older pages and the original article still say Timescale Cloud, which maps to Tiger Cloud today.
What is the difference between InfluxDB 3 Core and Enterprise?
According to the release notes, Enterprise is a superset of Core. Explicit per-database schema enforcement is Enterprise-only, Core rejects the setting, and Core remains Parquet-only without the upgraded storage engine. Version 3.12 also made user authentication and role-based access control generally available in Enterprise and added distributed compaction in beta. The notes do not state licence terms, so confirm the Core licence and Enterprise pricing with InfluxData before committing. Back up the catalog before moving to 3.12, because 3.11.x cannot read it afterwards.
Which TimescaleDB features need the Community licence?
The Apache 2 edition covers core hypertable functions and basic hyperfunctions such as time_bucket. Hypercore columnstore, continuous aggregates, retention and job policies, gap filling and SkipScan are in the Community edition under the Tiger Data License. You can self-host Community for free, but you cannot offer it as a service. Run SHOW timescaledb.license to see which mode your instance is in. If you only need plain hypertables and time_bucket, the Apache 2 edition may be enough, but most IoT teams want compression and continuous aggregates.
Should I use a ClickHouse LTS release for an IoT platform?
For production plants that upgrade rarely, yes. The ClickHouse docs and endoflife.date show LTS releases twice a year, each supported for one year: 26.8 until 27 August 2027 and 26.3 until 26 March 2027, while 25.8 has ended. Non-LTS releases only get fixes while they are among the last three minor versions. Check breaking changes first, since 26.9 changed the default compression to ZSTD(3) and the analyzer can no longer be disabled. Pin to an LTS tag and test upgrades on a staging replica with real sensor data.
Does the original benchmark data still apply?
Treat it as directional only. The original numbers came from earlier versions, including TimescaleDB 2.17 and ClickHouse 24.x, and we have not re-run them for this refresh. Engine changes such as InfluxDB 3’s DataFusion upgrade, TimescaleDB’s columnstore work and ClickHouse’s new default compression can shift ingest and query results. Test with your own sensor cardinality, retention window and query mix before choosing. A short proof of concept with a week of your own telemetry will tell you more than any published figure.
Pingback: OPC UA to Digital Twin: Ingestion Architecture