Regarding performance gains or cost savings, I can add that native multitenancy is only in the cluster version, and on single-node, we had to build tenant isolation ourselves with labels and query filters, so this could be improved. VictoriaMetrics could be improved further by addressing the BM Agent remote write protocol negotiation, which tries VictoriaMetrics native protocol first and then falls back to Prometheus, and together with some issues with external labels that cost us debugging time, it could be clearer and better documented. Victoria Traces is still in v0.x. I chose a rating of nine out of ten because native multitenancy is only in the cluster version, and on single-node, we had to build tenant isolation ourselves with labels and query filters.
Based on my experience, I am not aware of dedicated data access tools and query tools for VictoriaMetrics database, but I definitely know about Python integration with existing systems. For my knowledge, VictoriaMetrics is sufficient to achieve the results I want to achieve. At the moment I have not identified anything that I would request. I compared it with my experience on other time series databases, and it has a huge advantage, so I do not see the need for urgent improvements or optimizations. I think that access through programming libraries such as those for Python or R are already self-explanatory, so I would not find it difficult to find a very direct use of VictoriaMetrics. If VictoriaMetrics instead provided tools with a language closer to that of reporting, it would perhaps be more directly accessible without having to go through programming. The conversion of specific time series database languages into reporting languages could be one of the aspects that would improve the use of VictoriaMetrics.
VictoriaMetrics is quite a good project and quite easy to use overall, though some documentation could be improved. The main area that needs improvement in VictoriaMetrics is the documentation itself, as the support is adequate and the open-source project does provide replies within one to two days.
Overall, VictoriaMetrics is a very strong tool. One area for improvement is documentation and learning resources. While the documentation is good, some advanced use cases and configuration could be explained more clearly with real-world examples. Another improvement would be the UI and built-in visualization. VictoriaMetrics mainly relies on tools like Grafana, so having a more feature-rich native UI for basic monitoring and exploration would be helpful. On the integration side, while it works great with Prometheus and Grafana, expanding native integration with more tools like CI/CD platforms, alerting systems, and cloud-native services would be beneficial. In terms of support and troubleshooting, having more built-in diagnostics or guided debugging tools would be helpful. Right now, when issues happen, it often relies on logs and external tools. Also, for enterprise usage, strong features like RBAC, audit logs, and multi-tenant management would be enhanced. The improvements would include UI and built-in visualization. Also, query complexity can be a bit challenging for new users. Simplifying it or providing better guidance for query building would improve usability. Finally, enterprise features and ecosystem integration could be expanded further.
Teams that switch to VictoriaMetrics report 70% less RAM and 75% less disk (verified PeerSpot user reviews), and cloud bills up to 10x lower (Grammarly case study) — while keeping their existing dashboards and alerting rules working. It is an open source observability solution for metrics, logs, and traces: a drop-in replacement for Prometheus and other backends that keeps scaling when data volume, query speed, or cost no longer does. It runs anywhere — from a Raspberry Pi to thousand-core...
Regarding performance gains or cost savings, I can add that native multitenancy is only in the cluster version, and on single-node, we had to build tenant isolation ourselves with labels and query filters, so this could be improved. VictoriaMetrics could be improved further by addressing the BM Agent remote write protocol negotiation, which tries VictoriaMetrics native protocol first and then falls back to Prometheus, and together with some issues with external labels that cost us debugging time, it could be clearer and better documented. Victoria Traces is still in v0.x. I chose a rating of nine out of ten because native multitenancy is only in the cluster version, and on single-node, we had to build tenant isolation ourselves with labels and query filters.
Based on my experience, I am not aware of dedicated data access tools and query tools for VictoriaMetrics database, but I definitely know about Python integration with existing systems. For my knowledge, VictoriaMetrics is sufficient to achieve the results I want to achieve. At the moment I have not identified anything that I would request. I compared it with my experience on other time series databases, and it has a huge advantage, so I do not see the need for urgent improvements or optimizations. I think that access through programming libraries such as those for Python or R are already self-explanatory, so I would not find it difficult to find a very direct use of VictoriaMetrics. If VictoriaMetrics instead provided tools with a language closer to that of reporting, it would perhaps be more directly accessible without having to go through programming. The conversion of specific time series database languages into reporting languages could be one of the aspects that would improve the use of VictoriaMetrics.
VictoriaMetrics is quite a good project and quite easy to use overall, though some documentation could be improved. The main area that needs improvement in VictoriaMetrics is the documentation itself, as the support is adequate and the open-source project does provide replies within one to two days.
Overall, VictoriaMetrics is a very strong tool. One area for improvement is documentation and learning resources. While the documentation is good, some advanced use cases and configuration could be explained more clearly with real-world examples. Another improvement would be the UI and built-in visualization. VictoriaMetrics mainly relies on tools like Grafana, so having a more feature-rich native UI for basic monitoring and exploration would be helpful. On the integration side, while it works great with Prometheus and Grafana, expanding native integration with more tools like CI/CD platforms, alerting systems, and cloud-native services would be beneficial. In terms of support and troubleshooting, having more built-in diagnostics or guided debugging tools would be helpful. Right now, when issues happen, it often relies on logs and external tools. Also, for enterprise usage, strong features like RBAC, audit logs, and multi-tenant management would be enhanced. The improvements would include UI and built-in visualization. Also, query complexity can be a bit challenging for new users. Simplifying it or providing better guidance for query building would improve usability. Finally, enterprise features and ecosystem integration could be expanded further.