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."
}
}
]
}
