| > Prometheus only handle aggregated data, though. That's not true. You're referring to pull-based approach for metrics collection. It has its tradeoffs (like fixed interval scraping), but has a lot of benefits too (like higher reliability). Check the following link [0] from VictoriaMetrics docs, which supports both push and pull approaches. Prometheus also gained push support this year, though. However, the main difference between Prometheus-like systems (Thanos, Mimir, VictoriaMetrics) and more traditional DBs for time series like InfluxDB or TimescaleDB is that first are designed to reflect system's state, and last are designed to reflect system's events. That's the main difference in paradigm, data model, and query languages. There is a reason why PromQL is so easy in 99% of cases, and so complex and annoying when users want to express what they get used to in traditional databases. I'm saying this because I went through creating a Grafana datasource for ClickHouse [1] and I felt how complicated it is to express a most straightforward PromQL query in SQL, and vice versa. If you'd like to learn more about differences between common queries for plotting time series in PromQL and SQL see my talk here [2]. [0] https://docs.victoriametrics.com/keyConcepts.html#write-data [1] https://grafana.com/grafana/plugins/vertamedia-clickhouse-da... [2] https://youtu.be/_zORxrgLtec?t=835 |