The Best Database for IoT in 2026: An Honest Comparison

Most "best database for IoT" comparisons make the same mistake: they rank databases by ingestion throughput and stop there. That ranking is nearly useless, because the thing that actually breaks IoT projects is rarely raw write speed. It is the gap between the MQTT broker and the database, the fact that your gateway is a 512 MB ARM box in a factory with intermittent connectivity, and the moment six months in when someone asks you to join sensor readings against a device registry and you realize your database cannot do joins.

I worked at InfluxData. I now run Basekick Labs, where we build Arc, a columnar analytical database. I have a horse in this race and I will say so plainly whenever it matters. This post covers nine real options, each the right answer for a different kind of IoT deployment, and I will be specific about where each one wins and where it does not.

This is a companion to our 6 best time-series databases in 2026 comparison. That post evaluates engines generally. This one evaluates them specifically against IoT constraints, which are different enough to reorder the list.

The uncomfortable truth about MQTT

Let us clear up the single biggest misconception first, because it shapes every architecture decision downstream.

MQTT is a transport protocol. It does not store anything. Your broker (Mosquitto, EMQX, HiveMQ) receives messages, fans them out to subscribers, and forgets them. If nothing is subscribed and writing to disk, the data is gone. "MQTT database" is not a product category. It is a question about how you get data from a broker into storage.

And here is the part that surprises people: almost no general-purpose time-series database ingests MQTT natively. The dominant production pattern in 2026 is still:

sensors/PLCs → MQTT broker → Telegraf (mqtt_consumer) → database → Grafana

Telegraf's mqtt_consumer input plugin is the de facto standard bridge. The alternative is a broker rule engine: EMQX and HiveMQ can both transform and forward messages to a database sink without a separate agent.

Either approach works. Both mean an extra moving part to deploy, monitor, and keep alive during a network partition. Only three engines in this comparison skip it:

• Apache IoTDB embeds an actual MQTT broker. Devices publish directly to the database.
• TDengine ships a zero-code MQTT connector (MQTT 3.1/3.1.1/5.0).
• Arc compiles an MQTT subscriber into the binary. Arc acts as the MQTT client and connects out to your existing broker.

That last distinction matters and vendors blur it constantly. Arc does not embed a broker. You still run Mosquitto or EMQX. What you skip is Telegraf.

What actually matters when choosing

Rank these against your own situation before you look at a single benchmark.

1. Where does the workload live? Edge, cloud, or both. A database that is excellent centrally can be unusable on a DIN-rail gateway. This is the criterion that eliminates the most candidates fastest.

2. What is your MQTT path? Native subscriber, Telegraf, or broker rule engine. Each is one more process that can die at 3 a.m.

3. Cardinality. Every unique device ID, serial number, and location code multiplies your series count. Ten thousand devices with ten sensors each and three tags is not a rounding error, it is the failure mode that killed a generation of InfluxDB 1.x deployments.

4. Do you need joins? IoT data is meaningless without device metadata. "Which sensors on machines installed before 2023 in the Guadalajara plant are drifting?" is a JOIN. Some engines on this list cannot answer it without application-side stitching.

5. Retention and downsampling economics. One sensor at 1 Hz produces 86,400 points/day. Ten thousand sensors produce 864 million rows/day. You will not keep raw data forever. The two-tier pattern (roll up to aggregates, drop the raw) is table stakes.

6. License. AGPL, SSPL, and source-available licenses all get vetoed by some legal departments. Find out early, not after the POC.

Scale bands

Be honest about which band you are in. It eliminates most of the field.

Field guidance from practitioners is consistent: vanilla Postgres starts hurting somewhere between 10k and 200k points/sec depending on hardware and schema. Below that, do not over-engineer. A single Postgres instance with TimescaleDB will serve a surprising number of real IoT deployments for years.

The databases

1. TimescaleDB (Tiger Data)

TimescaleDB is a PostgreSQL extension. The company rebranded to Tiger Data in June 2025; the extension kept its name.

Why it wins for IoT. It is the best answer on this list to criterion #4, joins. Your device registry, customer table, maintenance schedule, and firmware inventory are almost certainly already in Postgres. TimescaleDB puts sensor readings in the same database, so correlating telemetry with metadata is one query with no application-side stitching. Hypertables partition by time automatically. Continuous aggregates give you the rollup tier. Hypercore's hybrid row-and-columnstore reports compression up to ~98% (vendor number, benchmark your own data).

Every Postgres tool, ORM, driver, and hire works on day one. That is worth more than most benchmark deltas.

Where it falls short for IoT. The edge. This is a full relational server, not a lightweight binary. Running Postgres on a constrained ARM gateway is possible but it is not what you want fighting for RAM against your control software. On the small edge tier, use SQLite and ship upstream.

The most-wanted features (Hypercore, continuous aggregates, retention policies) are under the Timescale License (TSL), which is source-available but not OSI open source and forbids offering it as a managed service.

MQTT path. Telegraf.

Best for. Teams already on Postgres, at small-to-medium scale, whose queries are metadata-heavy. This is the default recommendation for more IoT projects than any other entry here.

2. VictoriaMetrics

VictoriaMetrics is a Prometheus-compatible metrics database in Go.

Why it wins for IoT. The edge story is the best on this list among networked databases. It is a genuinely single small binary with no dependencies, and vmagent builds for 32-bit ARM, 64-bit ARM, PPC64, 386, and AMD64. Critically for IoT, vmagent buffers locally on disk and replays when connectivity returns. Intermittent links are the normal condition in vehicle telematics and remote industrial sites, not an exception.

High-cardinality handling is strong, compression is ~10x or better, and there is a specific index-size-reduction option aimed at IoT workloads. The docs claim deployments handling data from hundreds of millions of sensors.

Where it falls short for IoT. No SQL. PromQL and MetricsQL are excellent for "show me the p99 of this metric" and poor for "join these readings against my device table." If your IoT use case is really fleet monitoring and alerting, this is fine. If it is analytics, it is a wall.

It is also metrics-only. Logs and traces are separate products (VictoriaLogs, VictoriaTraces) with separate query interfaces.

MQTT path. Telegraf, writing via InfluxDB Line Protocol. There is an open feature request for native MQTT in vmagent; it is not shipped.

Best for. Constrained ARM edge fleets, metrics-shaped IoT, teams already fluent in PromQL, and anyone whose top requirement is "survive a flaky network."

3. InfluxDB 3

InfluxDB 3 Core and Enterprise reached GA in April 2025, rebuilt in Rust on Arrow, DataFusion, and Parquet.

Why it wins for IoT. Telegraf is built by InfluxData, and Telegraf is how most of the industry gets MQTT into a database. If your pipeline is already Telegraf-shaped, this is the shortest path. Line Protocol is first-class. Core is free, single-node, runs on a Raspberry Pi, and is explicitly positioned for edge and IoT. The v3 columnar engine removes the cardinality ceiling that made v1 and v2 painful for device data, which was historically the single most common InfluxDB-in-IoT failure.

There is also a built-in Python Processing Engine for in-stream transformation and alerting, which is genuinely useful at the edge.

Where it falls short. Three major versions with three query languages (InfluxQL, then Flux, then SQL) over roughly nine years. Teams that invested in Flux are starting over. The v1/v2 to v3 move is a migration, not an upgrade.

Core is optimized for recent data and does not do long-term compaction or historical query at scale; that is Enterprise. Early v3 also drew community complaints about database and retention limits in Core and missing native continuous aggregates. Enterprise pricing is per-vCPU and adds up quickly. We worked through the math in our TCO comparison. If you are evaluating a move off InfluxDB, we also wrote up the alternatives landscape.

MQTT path. Telegraf.

Best for. Telegraf-centric shops, and edge deployments where Core's recent-data window is enough.

4. GreptimeDB

GreptimeDB hit v1.0 GA in April 2026. Rust, columnar, object-storage-backed, unifying metrics, logs, and traces.

Why it wins for IoT. It has the most credible automotive and vehicle-edge story here. GreptimeDB Edge runs on ARM and Android; the same binary scales from a Raspberry Pi to a 100-node cluster, and edge nodes sync to cloud over the same APIs. Li Auto runs it on-vehicle across its EV production fleet, reporting 30–40x compression (10 exported files at 42 MB versus 1.3 GB in standard ASC log format) while working around real vehicle constraints: flash wear, limited cockpit resources, expensive uploads. That is a specific, named, hard-constraint IoT deployment, which is rarer in this space than you would hope.

The EMQX integration is tight. EMQX's rule engine writes to GreptimeDB with schema-on-the-fly, and EMQX Tables is a managed GreptimeDB-powered store. That is about as close to a first-class MQTT path as you get without native support.

SQL plus PromQL, with cross-signal joins as an explicit design goal.

Where it falls short. Maturity. v1.0 is months old. The Rust database ecosystem is younger, which means fewer integrations and a smaller pool of people who have operated it at 3 a.m. Clustering, HA, and some security features are Enterprise.

MQTT path. EMQX rule engine, or Line Protocol via Telegraf.

Best for. Automotive and vehicle telemetry, cloud-native teams consolidating observability, and anyone already running EMQX.

5. Apache IoTDB

Apache IoTDB is an ASF top-level project purpose-built for industrial IoT.

Why it wins for IoT. It is the only engine here with a built-in MQTT broker. Devices publish time-series directly to the database, no broker, no Telegraf, no rule engine. For an IIoT deployment where every additional process is another thing a plant technician has to understand, that is a real architectural simplification.

The data model is device-tree shaped, which maps naturally onto plant hierarchies (root.factory.line2.machine7.temperature). The columnar TsFile format is LSM-based, and the project's VLDB/SIGMOD papers report 10M values/sec ingest with sub-100ms queries. There is a lightweight embedded build with a ~32 MB runtime that runs on ARM7, plus edge-to-cloud sync.

Where it falls short. The Western community is small (~6.3k GitHub stars) and most documentation, adoption, and support gravitate toward Chinese manufacturing and energy. IoTQL is non-standard, though the v2.x table model improves SQL compatibility. It is JVM-based and operationally more involved than a single Go or Rust binary.

MQTT path. Native embedded broker.

Best for. Industrial IoT with plant-hierarchy data models, teams that want protocol-native ingestion with the fewest moving parts, and organizations comfortable with an ASF project whose center of gravity is not in the US or EU.

6. TDengine

TDengine is purpose-built for IIoT and edge.

Why it wins for IoT. The zero-code MQTT connector (MQTT 3.1/3.1.1/5.0) is native, with offline continuation and re-subscription for unstable networks. It also speaks OPC-UA, OPC-DA, PI, and Kafka out of the box, which covers the industrial protocol landscape better than anything else on this list. In a real factory, OPC UA sits between PLCs and the edge, and MQTT between edge and cloud; TDengine handles both ends.

The "supertable" template schema is designed for exactly the high-cardinality device problem: one schema template, millions of device instances. Edge-to-cloud replication is built in.

Where it falls short. TDengine SQL is not ANSI SQL, so your existing queries and BI tools need work. The Western ecosystem and Grafana integration are less mature than the alternatives here.

MQTT path. Native connector.

Best for. Industrial IoT with mixed protocols (MQTT plus OPC-UA), edge-to-cloud replication requirements, and high device counts.

7. ClickHouse

ClickHouse is a general-purpose columnar OLAP database, not an IoT engine, and it is on this list because at large scale it is often the correct answer anyway.

Why it wins for IoT. Central analytics on enormous sensor volumes. LowCardinality, MergeTree, and TTL-based retention handle the shape of IoT data well, and the scale evidence is not theoretical. EMQ runs ClickHouse Cloud beneath an MQTT-based IIoT platform serving 1,000+ enterprise customers, edge to cloud.

If your real problem is "we have 40 billion sensor readings and the analysts want to slice them arbitrarily," this is the most battle-tested engine here.

Where it falls short for IoT. Time is just another column, not the storage organizer. Last-known-value queries, time-bucketed aggregations, and time-range scans are not optimized the way purpose-built engines optimize them, and last-known-value is the single most common IoT query pattern.

It can be tuned as an edge aggregator with a memory cap and short TTLs, but it is not a natural small-footprint edge database. Operational complexity is higher, and there are real practical limits around part counts and concurrent inserts.

MQTT path. EMQX, Kafka, or another bridge.

Best for. The central analytics tier of a large IoT platform, usually alongside something lighter at the edge.

8. SQLite and DuckDB (the edge tier)

Not competitors to the above. Complements.

Why they win for IoT. For a truly disconnected edge device, the correct database is embedded. SQLite gives you zero-config, tiny-footprint, full-ACID local buffering with replay when the link returns. DuckDB gives you local analytical scans over Parquet if the gateway needs to compute rollups before uploading. libSQL/Turso adds embedded replicas and sync.

The pattern that works: SQLite at the disconnected edge for buffering and replay, a TSDB centrally for hot data and queries. A great many IoT architectures that failed did so by trying to make one database serve both roles.

Where they fall short. Neither is a fleet-scale central store. Concurrent write throughput is limited by design.

MQTT path. None. Your application code subscribes and writes locally.

Best for. The edge tier of a two-tier architecture. Pair with anything above.

9. Arc

Arc is a columnar analytical database for metrics, logs, traces, and events. I built it after leaving InfluxData. DuckDB is the query engine; storage is native Apache Parquet on S3, Azure Blob, MinIO, or local disk. It has been public since October 2025.

I am including it because on two of the six criteria at the top of this post, the MQTT path and metadata joins, Arc is the strongest option here. It is also the newest, and I will be specific about what that costs you.

Why it fits IoT. The MQTT subscriber is compiled into the binary. Arc connects out to your existing broker as an MQTT client, so there is no Telegraf process between the broker and storage. Concretely, what ships today: QoS 0, 1, and 2; TLS including client certificates; topic-to-table mapping so factory/line2/+/temp lands in the table you choose; per-subscription auto-start and lifecycle control via /api/v1/mqtt/subscriptions; encrypted credential storage; and exponential reconnect backoff for flaky links. Payloads are decoded as MessagePack or JSON.

That last detail is a real constraint and I would rather you hear it here than discover it in a POC: the native MQTT path takes MessagePack or JSON, not Line Protocol. If your devices publish Line Protocol over MQTT, you still want Telegraf in front. Arc's Line Protocol support is first-class, it just lives on the HTTP write path rather than the MQTT subscriber.

Single static Go binary. No JVM, no Postgres, no ZooKeeper, no Python runtime. That is what makes the edge story work: one file to ship to a gateway, air-gap friendly.

Full DuckDB SQL means the joins criterion is covered. Last-known-value via DISTINCT ON, windowed aggregation via time_bucket, plus CTEs and window functions. If your team writes Postgres SQL, they can query Arc today.

Storage is plain Parquet on infrastructure you own. For IoT, where data retention obligations often run to years, portability is not an abstract concern. If you stop using Arc, DuckDB, Spark, Polars, ClickHouse, and BigQuery all read your files as-is. No export step. We argued this at length in Parquet vs proprietary formats.

On ingestion, Arc does 19.9M records/sec via the MessagePack columnar protocol and 4.1M/sec via Line Protocol. Be appropriately skeptical of that first number: it is a first-party benchmark run on an Apple MacBook Pro M3 Max (14 cores, 36 GB RAM, 12 workers, 1000-record batches). It is not third-party validated and it is not server-grade hardware. Our ClickBench numbers against TimescaleDB and InfluxDB are more directly comparable.

Where it falls short. Arc is the youngest option here by a wide margin, public since October 2025, and the community is correspondingly small. It runs in production manufacturing environments today, including food and beverage operations in Central America, but I cannot name those customers, so treat it as a first-party claim until someone else publishes one. Our Citibike, satellite, vessel, and flight dashboards are live demos on open data feeds rather than customer deployments, and I would rather say so than let them read as logos.

The license is AGPL-3.0. This is intentional: it prevents cloud providers from forking Arc into a commercial offering without contributing back. But some enterprises avoid AGPL for legal reasons, and Arc Enterprise is commercially licensed and avoids that concern. Clustering and HA are Enterprise features, not OSS.

MQTT path. Native in-binary subscriber to an external broker, or Telegraf.

Best for. IoT teams that need analytical SQL depth and metadata joins, want one binary at the edge with no Telegraf sidecar, and want long-retention data in portable Parquet they own. Arc is open source and free; a Docker container and your existing broker is a twenty-minute evaluation.

Decision matrix

The query patterns you will actually write

Three patterns cover most IoT queries. Check your shortlist against all three.

Last-known-value. "What is the current reading for every sensor?" The most common IoT query and the one general-purpose OLAP engines handle worst. QuestDB has LATEST ON; TimescaleDB has SELECT DISTINCT ON and last(); Arc uses DISTINCT ON; InfluxDB has last(); IoTDB does it natively. ClickHouse needs argMax gymnastics.

Time-window aggregation. "Average temperature per machine per 5 minutes for the last week." TimescaleDB continuous aggregates, Arc time_bucket plus continuous queries, GreptimeDB Flow, VictoriaMetrics MetricsQL rollups. This is also your downsampling tier: compute it once, drop the raw.

Multi-sensor correlation with metadata. "Show vibration readings for pumps whose last maintenance was over 90 days ago." This needs a JOIN against a device table. Strong in TimescaleDB, Arc, GreptimeDB, ClickHouse. Weak or absent in VictoriaMetrics (PromQL) and awkward in InfluxDB.

If pattern three appears anywhere on your roadmap, do not choose a metrics-only engine, no matter how good its compression is.

What changed in 2026

• MongoDB's edge story regressed badly. Atlas Device Sync and the Atlas Device SDKs (Realm) reached end-of-life on September 30, 2025, with no automated migration tooling. If you were building offline-first IoT on Realm, that path is closed; teams have been migrating to Couchbase Mobile. MongoDB time-series collections still work centrally for document-shaped, moderate-volume telemetry, but the offline sync advantage is gone.
• AWS Timestream for LiveAnalytics closed to new customers, effective June 20, 2025. AWS now steers users to Timestream for InfluxDB.
• GreptimeDB v1.0 GA (April 2026) made the unified-observability-at-the-edge bet a real product.
• InfluxDB 3 Core and Enterprise GA (April 2025) removed the cardinality ceiling that pushed a lot of IoT teams off InfluxDB in the first place.

How to choose

Answer six questions and most of the field disappears:

1. Already on Postgres and need metadata joins? → TimescaleDB.
2. Constrained ARM edge with flaky connectivity, metrics-shaped data? → VictoriaMetrics.
3. Industrial, mixed protocols, want zero middleware? → TDengine or Apache IoTDB.
4. Vehicle or automotive edge? → GreptimeDB.
5. Billions of rows, central analytics tier? → ClickHouse.
6. Analytical SQL with metadata joins, one binary at the edge, no Telegraf sidecar, and data you keep in open Parquet? → Arc.

That sixth case is more common than it looks, because IoT data outlives the database you chose for it. Retention obligations run to years, and the engine you pick today probably is not the one querying that data in 2031. Most engines here store history in a format only they read, which turns "we are switching" into a migration project. InfluxDB 3 also writes Parquet, but it manages those files as engine internals rather than as your data. Arc writes plain Parquet to a bucket you own, laid out to be read directly by DuckDB, Spark, Polars, or ClickHouse without an export step. That makes switching a decision rather than an evacuation, which is worth weighing on a dataset you are legally obligated to keep for seven years.

Then design for two tiers. Most successful IoT architectures are not one database. They are SQLite or a local buffer at the disconnected edge, and a purpose-built TSDB or columnar engine centrally. Trying to make one engine do both is how projects end up with Postgres on a gateway or ClickHouse trying to answer last-known-value.

Finally, do not pick from a blog post, including this one. Shortlist two. Run a two-week POC each on your real sensor streams, at your real cardinality, with your real queries. Measure sustained ingest (not peak), p99 latency on your last-known-value and windowed queries, and compression on your actual data. Vendor multipliers, mine included, are marketing until you reproduce them.

Treat license as a gating criterion on day one, not day thirty. If your legal team bars AGPL, use Arc Enterprise, which is commercially licensed. If you might resell as a managed service, TimescaleDB's TSL terms matter. Apache 2.0 is the least friction.

FAQ

Is there a database that stores MQTT messages directly? Apache IoTDB embeds an MQTT broker, so devices publish straight to it. TDengine and Arc connect to an existing external broker as clients, with no separate agent. Everything else needs Telegraf's mqtt_consumer or a broker rule engine. The broker itself never stores your data.

Do I need a time-series database for IoT at all? Below roughly 10k points/sec, no. Postgres, or Postgres with TimescaleDB, will serve you well and you will keep the entire relational ecosystem. Move to a purpose-built engine when sustained ingest degrades write latency or when cardinality starts inflating your indexes.

What is the best database for IoT at the edge? For a disconnected device, SQLite. For a networked ARM gateway, VictoriaMetrics (best local buffering and replay), GreptimeDB Edge, InfluxDB 3 Core, TDengine, or Arc, all of which ship as a single binary. Not Postgres/TimescaleDB, and not JVM-heavy clustered systems.

How much storage does IoT data need? One sensor at 1 Hz is 86,400 points/day. Ten thousand sensors is 864 million rows/day. Uncompressed at roughly 50 bytes/row that is about 43 GB/day; at 10x compression, ~4.3 GB/day, or ~1.6 TB/year. This is why retention policies and downsampling are mandatory, not optional.

Can I query IoT data with standard SQL? Yes, with TimescaleDB (Postgres SQL), Arc (DuckDB SQL), ClickHouse, and GreptimeDB. InfluxDB 3 added SQL. TDengine SQL and IoTDB's IoTQL are non-standard dialects. VictoriaMetrics has no SQL at all.

How do I handle high cardinality from device IDs? Use a columnar engine. InfluxDB 3, GreptimeDB, ClickHouse, VictoriaMetrics, and Arc all handle millions of unique series without the index blowup that made InfluxDB 1.x and 2.x fail on device data. TDengine's supertable model is purpose-built for it.

---

This post will be updated quarterly. Last updated August 2026. If something here is wrong or out of date, tell me on GitHub or in Discord.

---

Related reading:

• 6 Best Time-Series Databases in 2026
• 5 InfluxDB Alternatives in 2026
• What Is a Columnar Database?
• Parquet vs Proprietary Formats
• Migrating from InfluxDB to Arc

Explore Arc:

• Arc documentation
• Compare Arc vs InfluxDB
• Compare Arc vs ClickHouse
• Star Arc on GitHub

---

About the author. I am Ignacio Van Droogenbroeck, founder of Basekick Labs and an ex-InfluxData engineer. I have been working with time-series and IoT data since 2018. I built Arc because I believe telemetry infrastructure should be built on portable, columnar formats rather than proprietary engines, and because IoT data outlives the database you put it in. The other eight options on this list are all real choices for the right team. If yours is an analytical workload on data you intend to keep, I would like you to try Arc.