This summary makes it seem like Victoria Metrics is barely compatible with Prometheus, but that can't be further from the truth in practice.
I remember in its early days MySQL had pretty poor SQL support (if you think about full standard) which did not prevent it from having huge success.
Or more recent example ClickHouse which I think similar to VictoriaMetrics as it does not fully implement SQL, but also adds many convenient extensions which are not part of the standard.
Chances are if you chose VictoriaMetrics you will find a lot more utility in advanced features of MetricsQL than you loose from exact compatibility with PromQL
We're currently running Prometheus + Thanos, and high cardinality timeseries are a real issue, which Victoria claims to be good at.
We found Cortex to be extremely over-engineered, extremely hard to tune (because of multiple configuration/argument refactors with incomplete doc cleanups) and found that it would just fall over under load. (Though to be fair, there wasn't much in the way of first-party deployment tooling at the time, so it was a hand-rolled Helm chart and at least 50% of the issues were likely my config).
In comparison, the first-party Victoria Metrics Helm chart worked straight out of the box, the maintainers have fixed multiple small issues within hours of me reporting them and we've thrown an extremely large amount of metrics at it with zero problems.
How do you include that in a CI/CD environment with regression testing?
These tests are great, because they spotted a few minor bugs in our PromQL implementation and these bugs were fixed quickly. See https://victoriametrics.github.io/CHANGELOG.html .
The majority of failed tests for VictoriaMetrics cannot be "fixed" due to deliberate choice made when designing MetricsQL: to rethink and to fix the most annoying and confusing parts of PromQL, while providing drop-in PromQL replacement for the majority of practical cases. See more details at https://victoriametrics.github.io/MetricsQL.html .
