InfluxDB vs Prometheus for Metrics and Sensor Data

Quick verdict

This page is for engineers who must decide where metrics and sensor readings go: a facilities or IoT platform where BMS points (AHU supply-air temperature, chiller kW, zone CO2), meter readings every 1 to 60 seconds and equipment states feed dashboards, alarms and CMMS work orders, often alongside the servers and services that run the platform. The two products are often mentioned together but solve different problems. For the wider architecture of streaming, storage and analytics layers, see the time-series and IoT data hub.

Prometheus, a Cloud Native Computing Foundation project, is a systems and service monitoring system. It scrapes metrics over HTTP from instrumented applications and exporters, stores them in a local time-series database, evaluates recording and alerting rules written in PromQL, and sends alerts to a separate Alertmanager. The latest release when checked was 3.15.1 (21 October 2026); it is licensed under Apache 2.0.

InfluxDB is InfluxData's time-series database. The current generation, InfluxDB 3, stores data as Parquet files and is queried with SQL or InfluxQL; InfluxDB 3 Core is the open source release (latest v3.12.1 when checked) and InfluxDB 3 Enterprise the commercial one. See the InfluxDB guide for its data model and editions.

Side by side

Key differences

Pull versus push, and why it matters for sensors

Prometheus collects by pulling: each target exposes current values on an HTTP endpoint and Prometheus scrapes it on a configured interval (the configuration reference gives a default scrape_interval of 1m; the 30s in the example below is an illustrative choice, set from how quickly alarms must react and how many series each target exposes). The project argues that pull makes it easy to tell when a target is down and to run extra monitoring instances. Pushing is supported through an intermediary Pushgateway, but the documentation recommends it essentially only for capturing the outcome of service-level batch jobs, not as a general push path.

Building devices rarely expose Prometheus endpoints. To scrape BMS data you would run an exporter that reads the BMS, the BACnet or Modbus gateway, or the MQTT broker and presents the latest values as metrics; Prometheus then samples whatever the exporter shows at scrape time. Readings that change between scrapes are not stored individually, and samples carry the scrape time unless the exporter exposes explicit timestamps (the exposition format allows an optional millisecond timestamp per sample). For alarm thresholds that is acceptable; for an energy record or sub-metering it is not. The Prometheus overview itself says that if you need 100% accuracy, such as for per-request billing, Prometheus is not a good choice.

InfluxDB receives pushed writes: a gateway, Telegraf (with its MQTT consumer and many other inputs) or your own service sends line protocol with the device timestamp, and each reading is stored. This fits the streaming layer of an IoT pipeline, where devices publish to an MQTT broker or Kafka and consumers write every message to the database. See Kafka vs MQTT for that layer.

# Illustrative configuration, not run here: keys from the Prometheus configuration documentation;
# the target host is a placeholder and 30s is an illustrative interval; check every setting
# against the documentation for your version before use.
global:
  scrape_interval: 30s
scrape_configs:
  - job_name: bms_exporter
    static_configs:
      - targets: ["bms-exporter.plant.local:9100"]

# Illustrative, not run here: line protocol format from the InfluxDB 3 Core documentation
ahu,site=hq,ahu_id=ahu-02 supply_air_temp=16.8,fan_speed_pct=62i,mode="occupied" 1793091600000000000

Data model: labels and floats versus tags and typed fields

In Prometheus every series is identified by a metric name and a set of labels, and each sample is a float64 (or a native histogram) with a millisecond timestamp. Strings appear only as label values, so a mode such as "occupied" becomes a label or an enumerated number. Every distinct label combination is a separate series, so labels must have bounded values: putting a work-order number or a free-text alarm message in a label creates a new series per value.

InfluxDB 3 tables have tags (identifiers such as site, ahu_id) and fields typed as float, integer, unsigned integer, boolean or string, with nanosecond timestamps. That is closer to what a BMS historian stores: numeric values, status strings and flags in one row. Tag columns are fixed once a table exists, and the InfluxDB 3 documentation says tag cardinality no longer affects overall performance as it did in earlier versions; still model point lists carefully. The high-cardinality tags guide covers both systems' pitfalls.

Retention, remote write and long-term storage

Prometheus keeps data in a local TSDB of two-hour blocks that are compacted in the background. If neither --storage.tsdb.retention.time nor --storage.tsdb.retention.size is set, retention is 15 days. Local storage is not clustered or replicated, so the documentation advises treating it like any single-node database; with the right architecture it can hold years of data, but most deployments do not. The TSDB setting out_of_order_time_window defaults to 0s; the configuration reference describes it as how old an out-of-order or out-of-bounds sample can be relative to the TSDB's newest timestamp and still be ingested, so with the default, out-of-order samples are rejected. That matters when a gateway replays a buffer; the behaviour was not run here.

For long-term storage Prometheus uses remote write: it streams samples from its write-ahead log to one or more HTTP endpoints using the Remote-Write protocol (1.0 is stable, 2.0 experimental). Receivers include Thanos and Grafana Mimir (both built for highly available, long-term Prometheus storage), Cortex and many vendors. If a remote endpoint is down, failures are retried without loss for up to about two hours; after that the WAL is compacted and unsent data is lost. Agent mode runs Prometheus as a scrape-and-forward agent with querying, alerting and local storage disabled. Prometheus can also receive data: its remote write receiver (--web.enable-remote-write-receiver) and OTLP receiver (--web.enable-otlp-receiver) are both off by default because Prometheus may run without authentication.

InfluxDB keeps data until the database's retention period expires, and by default data does not expire. In InfluxDB 3 Core the retention period can only be set when a database is created, so plan it up front; data persists as Parquet on local disk or object storage. Downsampling runs in the Python processing engine.

The two connect in both directions. InfluxDB 1.x documented native /api/v1/prom/write and /api/v1/prom/read endpoints for Prometheus remote write and read; that page is marked as documentation for an earlier version. The InfluxDB 3 Core and Enterprise HTTP write pages we checked list line protocol endpoints (/api/v3/write_lp for new workloads, and the v1 and v2 compatible /write and /api/v2/write) and do not describe a Prometheus remote write endpoint; check the current documentation for your edition before relying on that. The route the InfluxData documentation does describe is Telegraf: its http_listener_v2 input with the prometheusremotewrite data format receives Prometheus remote write, its Prometheus input scrapes /metrics endpoints, and its prometheus_client output exposes Telegraf-collected metrics for Prometheus to scrape.

# Illustrative configuration, not run here: adapted from the Telegraf documentation;
# the port and path are placeholders. Check every setting against the documentation
# for your version before use.
[[inputs.http_listener_v2]]
  service_address = ":1234"
  paths = ["/receive"]
  data_format = "prometheusremotewrite"

# prometheus.yml (illustrative, not run here): forward samples to that listener;
# keys from the Prometheus documentation, host name is a placeholder
remote_write:
  - url: "http://telegraf.plant.local:1234/receive"

Queries and alerting

PromQL is a functional language built for selecting and aggregating series in real time: rates of counters, averages over windows, comparisons for alerts. Recording rules precompute expensive expressions into new series, which is Prometheus's form of downsampling, and alerting rules fire alerts that the Alertmanager groups, silences, inhibits and routes to email, chat or on-call tools. For a CMMS, an Alertmanager webhook can call an API that raises a work order.

# Illustrative configuration, not run here: rule file syntax from the Prometheus documentation;
# the 16 C threshold and the 10m and 15m windows are illustrative values.
groups:
  - name: ahu
    rules:
      - alert: SupplyAirTooWarm
        expr: avg_over_time(bms_supply_air_temp_celsius{site="hq"}[10m]) > 16
        for: 15m
        labels:
          severity: warning

InfluxDB 3 uses SQL (Apache DataFusion) and InfluxQL, which suit reporting questions such as hourly averages per AHU for the last month or energy per meter per day. It has no built-in alert manager; threshold checks run as processing engine plugins (Python triggered on write, on a schedule or on request) or in an external tool such as Grafana alerting.

-- Illustrative, not run here: InfluxDB 3 SQL pattern from the InfluxDB 3 Core documentation;
-- check it against the documentation for your version before use.
SELECT DATE_BIN(INTERVAL '1 hour', time, '2026-01-01T00:00:00Z'::TIMESTAMP) AS time,
       ahu_id, avg(supply_air_temp) AS avg_temp
FROM ahu
WHERE time >= now() - INTERVAL '30 days'
GROUP BY 1, ahu_id
ORDER BY 1;

Operations, security and scaling

Each Prometheus server is standalone and does not depend on network storage, which is why the project positions it as the system you use during an outage. High availability means running two identical servers that scrape the same targets, plus the Alertmanager's HA mode; scaling means splitting targets across servers, or moving to Thanos or Mimir. Prometheus does not support NFS for local storage. TLS and basic authentication are configured through a web configuration file (--web.config.file), which the documentation still marks as experimental; do not expose the remote write or OTLP receivers without it.

InfluxDB 3 Core is a single node; high availability, read replicas and historical query capability are InfluxDB 3 Enterprise features. Core starts with authentication enabled and uses admin tokens, each of which grants access to every action on the server, so keep it on a private network and put a gateway in front of it. For sizing either system, multiply series by samples per second by retention and measure on a sample; see storage sizing for sensor telemetry.

The Prometheus project's own comparison page describes InfluxDB as better for event logging and long-term storage in its commercial clustered form, and Prometheus as better for metrics, querying and alerting. That page compares Prometheus with InfluxDB plus Kapacitor and continuous queries, and describes InfluxDB storage as a log-structured merge tree variant; it does not describe InfluxDB 3, which persists Parquet files, so treat its InfluxDB details as historical.

Pricing and licensing

Prometheus is open source under Apache 2.0 and carries no licence fee; costs are the servers, disks and the people who run them. Long-term storage projects such as Thanos and Grafana Mimir are also open source, and several cloud providers sell managed Prometheus-compatible services priced by samples ingested, stored and queried; check each provider's pricing page, since we did not compare them here.

InfluxDB 3 Core: InfluxData's pricing page states that it "is open source and free to download and run with no license required". InfluxDB 3 Enterprise is priced through sales with a 30-day free trial. InfluxDB Cloud Serverless is usage-based (data in, queries, storage and data out) with a free tier limited to 30-day retention; the pricing page lists its unit prices without stating a region, so they are not quoted here; see TimescaleDB vs InfluxDB for the pricing model.

Licences. The Prometheus repository's LICENSE file is the Apache License 2.0, whose section 2 grants "a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form", subject to the licence's conditions, including those on redistribution in section 4. The InfluxDB repository states: "The open source software we build is licensed under the permissive MIT or Apache 2 licenses at the user's choosing." (texts in LICENSE-MIT and LICENSE-APACHE). InfluxDB 3 Enterprise runs under a licence from InfluxData; its licence page lists Trial, At-Home and Commercial licences. Not legal advice: this is a factual summary of the licence texts as published on 27 October 2026; read the licences for the versions you use and take legal advice for your situation.

Pricing checked on the vendors' official pages on 27 October 2026. Prices change; confirm before buying.

Where each one leads

Limitations

When to choose each

When neither is right

• Readings must be joined with assets and work orders in SQL: a relational time-series option such as TimescaleDB fits better; see TimescaleDB vs InfluxDB.
• You want a managed observability platform rather than running servers: see Prometheus vs Datadog.
• You need a Prometheus-compatible store with lower resource use or longer retention: see the VictoriaMetrics guide.
• High-frequency telemetry with SQL is the main need: see QuestDB vs InfluxDB and the time-series database selection guide.

Final recommendation

Frequently asked questions

Sources

• Prometheus: overview
• Prometheus: data model
• Prometheus: storage
• Prometheus: configuration
• Prometheus: agent mode
• Prometheus: remote write tuning
• Prometheus: alerting overview
• Prometheus: when to use the Pushgateway
• Prometheus: using Prometheus as an OpenTelemetry backend
• Prometheus: recording rules
• Prometheus: querying basics (PromQL)
• Prometheus: integrations (remote endpoints and storage)
• Prometheus: comparison to alternatives
• Prometheus: FAQ
• Prometheus: HTTPS and authentication
• Prometheus: exposition formats
• InfluxDB 3 Core: schema design best practices
• Prometheus GitHub repository
• Prometheus releases on GitHub
• Thanos
• Grafana Mimir
• InfluxDB 3 Core documentation
• InfluxDB 3 Core: get started and data model
• InfluxDB 3 Core: create a database (retention)
• InfluxDB 3 Core: data retention internals
• InfluxDB 3 Core: processing engine and plugins
• InfluxDB 3 Core: manage tokens
• InfluxDB 1.x: Prometheus endpoints support
• InfluxDB 3 Core: write data with the HTTP API
• InfluxDB 3 Enterprise: write data with the HTTP API
• Telegraf: Prometheus Remote Write input data format
• Telegraf: Prometheus input plugin
• Telegraf: Prometheus client output plugin
• InfluxDB GitHub repository
• InfluxData pricing
• Prometheus repository: LICENSE
• Apache License, Version 2.0 (apache.org)
• InfluxDB repository: LICENSE-MIT
• InfluxDB repository: LICENSE-APACHE
• InfluxDB 3 Enterprise: manage your license

Checked October 2026.

How we research comparisons: our editorial method.