Are there better alternatives to InfluxDB?

Yes, in specific cases, but the better choice depends on what the workload actually needs. InfluxDB rebuilt its storage engine for version 3.0 around Apache Arrow, Parquet and a Rust-based query engine called DataFusion, and InfluxData's own benchmarks claim up to 100x faster queries on high-cardinality data and 10x higher ingest throughput versus the older Go-based versions. That closes some gaps, but it doesn't make InfluxDB the right fit for every time-series job.

When do alternatives make more sense?

If the workload is mostly infrastructure and application metrics, Prometheus is often the simpler starting point. It scrapes metrics from HTTP endpoints on a schedule instead of requiring a separate ingestion pipeline, and it plugs into Grafana and Alertmanager with little extra setup. Prometheus was never designed as a long-term time-series store on its own, though, which is where its ecosystem of remote-storage backends comes in.

When does VictoriaMetrics make more sense?

When Prometheus starts struggling with cardinality or ingest volume, VictoriaMetrics is a common next step. It accepts Prometheus remote write, exposes a PromQL-compatible query language called MetricsQL, and runs as a single binary, which keeps operations simpler than managing a separate metrics cluster.

When does TimescaleDB make more sense?

If the data already sits next to relational tables, or the team wants standard SQL joins and window functions instead of Flux or InfluxQL, TimescaleDB is usually the better fit. It's a PostgreSQL extension rather than a separate database, so backups, replication and access control reuse tooling a Postgres team already runs.

For heavy analytical queries over large historical datasets, ClickHouse and QuestDB are also worth testing. Both store data in columnar format and speak SQL, and both can outperform InfluxDB on scan-heavy aggregate queries.

When is InfluxDB still the right call?

InfluxDB remains a sensible default when a team wants one system handling ingestion, storage and querying for IoT sensor data or application telemetry, without wiring together separate tools for metrics collection and long-term storage. Teams already running InfluxDB 1.x or 2.x may get more value from upgrading to 3.x than from migrating to a different database entirely.

Before switching, weigh the migration cost against the actual bottleneck. Query language lock-in, whether that's Flux, InfluxQL or PromQL, and rebuilding existing dashboards are usually the real cost of moving, not raw database throughput.