InfluxDB
The purpose-built time series database — rewritten in Rust with SQL support, Parquet storage, and 10-20x compression in v3.
Best for: DevOps teams collecting infrastructure metrics, IoT platforms ingesting sensor data, and anyone running Prometheus who needs SQL queries and longer-term retention.
TL;DR
- What it is: An open-source (Apache 2.0) time series database purpose-built for metrics, events, IoT sensor data, and real-time analytics. Now on version 3, completely rewritten in Rust with Apache Arrow and Parquet.
- Who it’s for: DevOps teams collecting infrastructure metrics, IoT platforms ingesting sensor data, and anyone running Prometheus + Grafana who wants longer retention and SQL queries.
- Cost savings: InfluxDB Cloud charges $0.002/MB ingested plus query and storage fees. Self-hosted InfluxDB 3 Core is free on your own hardware. A $10-20/month VPS handles most small-to-medium monitoring workloads.
- Key strength: Sub-10ms last-value queries, native SQL support via DataFusion, Parquet-based storage with 10-20x compression, and a diskless architecture that can use S3/GCS for cold storage.
- Key weakness: The v3 rewrite broke backward compatibility. Flux query language is deprecated. Migrating from v1/v2 requires data export and reimport. The community is still absorbing these changes.
What is InfluxDB
InfluxDB is a database designed specifically for time-stamped data — the kind generated by servers, sensors, applications, and financial systems. Traditional relational databases can store timestamps, but they aren’t optimized for the patterns that time series data creates: constant high-volume writes, time-range queries, downsampling, and retention policies.
The project has gone through three major architectural generations. InfluxDB 1.x (Go, TSM storage engine, InfluxQL query language) was the original that made the project famous. InfluxDB 2.x added a task engine, the Flux functional query language, and a built-in UI. InfluxDB 3.x is a complete ground-up rewrite in Rust, using Apache Arrow for in-memory processing and Apache Parquet for persistence, with SQL as the primary query language.
The company behind it, InfluxData, has been operating for over a decade and claims the #1 position among time series databases according to DB-Engines rankings. The GitHub repository sits at 31,344 stars.
InfluxDB 3 Core (the open source version) went GA on April 15, 2025. It’s a single-node deployment suitable for most self-hosted use cases. InfluxDB 3 Enterprise adds clustering and high availability. InfluxDB Cloud runs the same v3 engine as a managed service.
Why people choose it over Prometheus, TimescaleDB, and Datadog
Versus Prometheus + Grafana. Prometheus is the default monitoring stack in the Kubernetes world — free, integrates with everything, massive ecosystem. But Prometheus was designed for short-term metric storage (typically 15-30 days) and struggles with high-cardinality data and long-term retention. InfluxDB handles longer retention natively via Parquet files that compress 10-20x and can be offloaded to object storage. Many teams run both — Prometheus for alerting and short-term dashboards, InfluxDB for long-term analytics.
Versus TimescaleDB. TimescaleDB extends PostgreSQL, so you get full SQL, JOINs, and the entire PostgreSQL extension ecosystem. InfluxDB is purpose-built and optimized only for time series workloads. On pure time series queries, InfluxDB v3 typically wins with sub-10ms last-value queries. On complex queries involving JOINs or mixed relational-temporal data, TimescaleDB wins because InfluxDB doesn’t support JOINs. If you already run PostgreSQL and want to add time series capability, TimescaleDB is the pragmatic choice.
Versus Datadog. Datadog is the 800-pound gorilla of SaaS observability. It works beautifully and costs accordingly — a typical small team’s bill runs $200-1,000/month. Self-hosted InfluxDB + Grafana + Telegraf provides roughly 70% of the functionality at 5-10% of the cost, but you maintain it yourself.
Features: what it actually does
InfluxDB 3 Core (open source):
- Rust-based engine with Apache Arrow for in-memory columnar processing
- Apache Parquet for persistent storage with 10-20x compression
- Sub-10ms last-value queries, 30ms for distinct metadata
- Diskless architecture: data can live in object storage (S3, GCS, Azure Blob) with local caching
- SQL query engine via DataFusion with FlightSQL and HTTP query APIs
- InfluxQL backward compatibility for v1/v2 migrations
- Embedded Python VM for plugins and triggers
- Line Protocol compatibility with v1 and v2 write APIs
- Docker, RPM, Debian packages, and tarballs
Ecosystem (Telegraf + integrations):
- Telegraf: open source collection agent with 5,000+ plugins for metrics, logs, and events
- IoT protocol support, Kubernetes monitoring, Prometheus remote write
- OpenTelemetry integration for unified metrics, logs, and traces
- Client libraries for Python, JavaScript, Go, C#, Java
- Grafana as the primary visualization layer
What’s NOT in v3 Core:
- No clustering or high availability — that’s Enterprise
- No built-in UI — use Grafana
- Flux query language deprecated — use SQL or InfluxQL
- No JOINs in the query engine
Pricing: SaaS vs self-hosted math
Self-hosted InfluxDB 3 Core:
- Software license: $0 (Apache 2.0)
- VPS: $10-20/month on Hetzner or DigitalOcean for a small monitoring workload
- Storage: Parquet compression means 10-20x less disk than raw data
Datadog for comparison:
- Infrastructure monitoring: $15/host/month
- APM: $31/host/month
- A 10-server setup easily hits $300-500/month
Concrete savings math for a DevOps team monitoring 20 servers:
- Datadog: 20 hosts x $15/host = $300+/month = $3,600+/year
- Self-hosted InfluxDB 3 Core on $15/month Hetzner VPS: $180/year
- Annual savings: ~$3,400
Deployment reality check
The v3 rewrite changed the deployment story. InfluxDB 3 Core is a single Rust binary that’s simpler to run than the previous Go versions.
What you actually need:
- A Linux server with 2+ CPUs, 4GB+ RAM (more for high-cardinality workloads)
- Docker (easiest path) or install from RPM/DEB/tarball
- Optionally: S3-compatible storage for the diskless architecture
- Telegraf installed on machines you want to monitor
- Grafana for visualization (InfluxDB 3 Core has no built-in UI)
What can go sideways:
- The v1/v2 to v3 migration is real pain. Storage engines are incompatible. You must export data from v1/v2 and reimport into v3. For large datasets, this can take hours to days.
- Flux is deprecated. If you invested heavily in Flux queries, you need to rewrite them in SQL or InfluxQL.
- No built-in UI. InfluxDB 2.x had a built-in dashboard. v3 Core does not — you need Grafana.
- Enterprise features cost money. Clustering and high availability require InfluxDB 3 Enterprise.
- High cardinality kills performance. Keep cardinality in fields, not tags.
Realistic time estimate: 30-60 minutes to a working InfluxDB + Telegraf + Grafana stack via Docker Compose. For migrating from v1/v2: 2-8 hours depending on data volume and Flux query rewrites.
Who should use this
Use InfluxDB if:
- You’re collecting time series data (server metrics, IoT sensors, application performance) and need fast queries with long retention.
- You want SQL-based querying of time series data without learning a custom language.
- You need Parquet-based storage with S3 offloading for cost-efficient long-term retention.
- You’re comfortable with the single-node limitation of the open source Core edition.
Use Prometheus + Grafana instead if:
- You’re in a Kubernetes-native environment with short-term retention needs (15-30 days).
- You need the Prometheus ecosystem of exporters and alerting rules.
Use TimescaleDB instead if:
- You already run PostgreSQL and want to add time series capability.
- You need JOINs between time series and relational data.
Use Datadog/New Relic instead if:
- You don’t want to maintain infrastructure and have the budget for SaaS observability.
- You need a unified platform (metrics + logs + traces + APM) rather than assembling components.
Sources
This review synthesizes 5 independent third-party articles along with primary sources from the project itself. Inline references throughout the review map to the numbered list below.
- [1] dev.to (2025-06-20) — “Mastering InfluxDB: Your Essential Guide to Time Series Databases” — tutorial-overview (link)
- [2] calmops.com (2026-03-05) — “InfluxDB Trends 2025-2026: Time-Series Database Evolution” — trends-evolution (link)
- [3] blog.ippon.tech (2021-06-29) — “A Beginner’s Guide to InfluxDB: A Time-Series Database” — tutorial-beginner (link)
- [4] thenewstack.io (2025-01-01) — “InfluxDB 3.0: A Complete Rewrite in Rust with Apache Arrow and Parquet” — critical-migration (link)
- [5] blog.timescale.com (2024-09-01) — “InfluxDB vs TimescaleDB: A Time Series Database Comparison” — comparison (link)
- [6] GitHub repository — official source code, README, releases, and issue tracker (https://github.com/influxdata/influxdb)
- [7] Official website — InfluxDB project homepage and docs (https://www.influxdata.com)
References [1]–[7] above were used to cross-check claims about features, pricing, deployment, and limitations in this review.
Deploy
Features
Integrations & APIs
- Plugin / Extension System
Related Databases & Data Tools Tools
View all 122 →Supabase
99KThe open-source Firebase alternative — Postgres database, Auth, instant APIs, Realtime subscriptions, Edge Functions, Storage, and Vector embeddings.
Prometheus
63KAn open-source monitoring system with a dimensional data model, flexible query language, efficient time series database and modern alerting approach.
NocoDB
62KTurn your existing database into a collaborative spreadsheet interface — without moving a single row of data.
Meilisearch
56KLightning-fast, typo-tolerant search engine with an intuitive API. Drop-in replacement for Algolia that you can self-host for free.
DBeaver
49KFree universal database management tool for developers, DBAs, and analysts. Supports 100+ databases including PostgreSQL, MySQL, SQLite, MongoDB, and more.
Milvus
43KMilvus is a high-performance open-source vector database built for AI applications, supporting billion-scale similarity search with sub-second latency.