Ask HN: State of Timeseries Databases in 2024
The user is exploring alternatives to InfluxDB for sensoric time series data due to stalling issues and migration challenges, considering VictoriaMetrics and seeking recommendations for other databases.
The user is seeking alternatives to InfluxDB for storing sensoric time series data due to issues with the database stalling and the challenges associated with migrating to newer versions. Initially, InfluxDB was chosen for its simplicity and open-source focus, but the user notes a shift towards enterprise and cloud solutions, particularly with the upcoming v3 version lacking an open-source option. As the user's needs have evolved, particularly regarding scalability, they are considering VictoriaMetrics as a potential alternative. They are asking for recommendations on other time series databases to explore.
- The user is experiencing issues with InfluxDB, including stalling and migration challenges.
- There is a noted shift in InfluxDB's focus from open-source to enterprise solutions.
- Scalability has become a more significant concern for the user as their data needs have grown.
- VictoriaMetrics is being considered as a potential alternative to InfluxDB.
- The user is seeking recommendations for other time series databases.
Related
6 commentsBoth victoria metrics and questdb are compatible (ingestion-wise) with the InfluxDB Line protocol, so migration would be smoother than with other databases. Just point the old ingestion script to the new server URL, and data will start flowing in.
Taking a broader view, the time series database landscape is split into three categories (sorry for adding complexity!):
1. Observability (metrics from your hardware): Prometheus, and other engines that work well with Prometheus such as Victoria Metrics. I think their language is tightly coupled with PromQL. InfluxDB 1.X and 2.X used to be in this camp and were the market-leading solution for observability before Prometheus came along and got incredible adoption. Chronosphere built with m3db is also a big name in this category.
2. General purpose: TimescaleDB is built on top of Postgres, and is now seen increasingly as a super postgres that can also deal with time series data, amongst other things (now focusing on vectors as well).
3. Specialized: kdb+, QuestDB, some OLAP databases that can also do time series (Clickhouse & Druid), and perhaps InfluxDB 3.0 even though it's not OSS yet. Here the focus is on performance, and the data loads tend to be more significant. Industries and use cases often paired with demanding data loads, such as financial services, often require such specialized databases. Some have their prop language (kdb+ with Q), some are closed source (kdb+), and others are OSS & use SQL (questdb, clickhouse, druid). InfluxDB 3.0 also uses SQL (from DataFusion's query engine) but is not OSS yet.
VictoriaMetrics is awesome. Clickhouse is another popular choice if you need more flexible model and would like SQL
InfluxDB is a great project, but as you said, the v3 migration is painful and is still WIP. About the performance, We already did some benchmark GreptimeDB vs. InfluxDB v2, you can find it in our blog.