CloudCostCompare

Guides

Time-series database costs: Azure Data Explorer vs Timestream for InfluxDB vs Bigtable

Updated 27 Oct 2026

Every reading your machines send has to be stored somewhere that can answer “what was the temperature on line 3 between 2 and 4 am?” quickly. That is a time-series database’s job. In factory workloads it is frequently the largest cost, ahead of the IoT gateway, because it runs around the clock whether anyone is querying it or not.

The three clouds take different approaches, and the differences matter more than the hourly rates.

Azure Data Explorer: a cluster of VMs plus a markup

Azure Data Explorer (ADX, the engine behind Kusto queries) runs on a cluster of virtual machines. You pay for:

  • The engine VMs, at normal VM prices, for every hour they run;
  • A markup per engine vCPU, which is the charge for the Data Explorer service itself;
  • Storage for data beyond what the VMs cache locally.

The catch for small projects is the minimum of two engine nodes for a production cluster with an uptime SLA. A dev/test option with a single node exists, but it has no SLA. So even a small fleet pays for two always-on VMs plus markup.

In return, ADX is very fast at aggregations over large volumes, and recent data sits on the nodes’ local SSD cache. Larger fleets get good value from that fixed cost, because adding data does not add nodes until the cache or query load demands it.

Amazon Timestream for InfluxDB: one managed instance

AWS’s time-series option for new customers is Timestream for InfluxDB, a managed InfluxDB instance. (The older Timestream for LiveAnalytics is closed to new customers.) You pay for:

  • The instance, per hour, sized by vCPU and memory;
  • Storage, per GB-month, for the provisioned volume.

There is no cluster minimum, so a small deployment can start on one modest instance. The trade-off is that you choose and resize the instance yourself, and high availability (a standby in another zone) roughly doubles the instance cost.

Google Cloud Bigtable: nodes plus storage

Bigtable is a wide-column database rather than a dedicated time-series engine, but it is Google’s standard home for high-volume sensor data. You pay for:

  • Nodes, per node-hour, with a minimum of one node per cluster;
  • SSD storage per GB-month (HDD storage is cheaper but slower).

Bigtable scales throughput by adding nodes, and Google’s autoscaling can add and remove them with load. It has no built-in time-series query language, so dashboards usually read it through another layer (or the data is also loaded into BigQuery for analysis), which can add cost.

What actually drives the bill

Factor Why it matters
Minimum footprint Two ADX nodes, one InfluxDB instance or one Bigtable node run 24/7 regardless of load. For small fleets this minimum is the bill.
Compression Sensor readings compress very well (often 5:1 or better). Storage costs are usually small next to compute.
Retention Keeping years of raw readings in the database is expensive. Downsample old data, or move it to object storage.
Query load Heavy dashboards with many users can force bigger instances or more nodes, even when write volume is modest.
High availability Standbys and replicas multiply the compute cost. Decide early whether you need them.

Which is cheapest?

It depends almost entirely on scale:

  • Small fleets (hundreds of devices) are dominated by the minimum footprint, which tends to favour a single right-sized instance.
  • Large fleets spread the fixed cost over much more data, and engines built for scale-out analytics start to win on cost per query.

Rather than guess, compare the live numbers: