VictoriaMetrics Reviews

VictoriaMetrics is our time-series store, and we have Helm charts that ship an embedded single-node VictoriaMetrics with 30-day rotation by default. Teams that already run VictoriaMetrics can point Cubolt at their own instance.

Each connected cluster runs our agent plus a BM Agent sidecar that scrapes kubelets, node-exporter, and kube-state-metrics, and everything lands in VictoriaMetrics while our insights engine, resizing dashboard, and AI copilot all query it with PromQL.

Regarding our main use case, VictoriaMetrics has metrics like BM the duplicated samples total, showing us that about half the samples we were sending were being thrown away. Our agent was sampled every 15 seconds while the default was set to 30, and we aligned the two, cutting ingestion by about 40% without losing any data.

VictoriaMetrics has positively impacted our organization because we chose it for efficiency, simplicity, one binary and cost, and it's straightforward embedded in our Helm chart, so it works out of the box.

I can share specific results or metrics that highlight the positive impact we've seen since adopting VictoriaMetrics.

The best features VictoriaMetrics offers include PromQL compatibility, which ensures the whole Kubernetes ecosystem just works, along with simple operations, one binary in a stateful set with health checks and native OTLP ingestion. We are adding Victoria Traces for traces from our AI agents.

Frontier compatibility in VictoriaMetrics helps our team by being very stable in production for larger or high cardinality environments, and our design is to move to the cluster version on a server or an external VictoriaMetrics.

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.

We have been using VictoriaMetrics since April 2026, which is about six months, and it has been great.

VictoriaMetrics's scalability in our experience has been very easy; we deploy and embed it in our Helm chart and it works out of the box.

Before using VictoriaMetrics, we previously utilized solutions such as Prometheus and Grafana, Elastic, and DataDog.

VictoriaMetrics is deployed in our organization in a public cloud and it is very easy.

We have seen a return on investment with at least 30% of estimated cost saved with VictoriaMetrics.

Regarding pricing, setup cost, and licensing, we are using open source today.

Before choosing VictoriaMetrics, we evaluated options such as Prometheus alone, Thanos, and Mimir.

I would rate VictoriaMetrics a nine out of ten. I think VictoriaMetrics is a great solution because you can have traces, metrics, and logs in one solution, and it is easy to deploy in every infrastructure, such as on-premise, cloud, or hybrid infrastructure.

I am using VictoriaMetrics to monitor approximately 300 servers and several existing processes on each server, handling data coming from thousands of electronic tags. I needed a database that was fast and would later allow me to perform data analysis.

Currently, I use VictoriaMetrics in combination with Prometheus and Grafana to manage this amount of data.

VictoriaMetrics has had a positive impact on my organization, though the system I created is still in testing. The company has not yet evaluated the benefit of having this monitoring system.

During these tests, the benefit of integration with already existing standards has made it easier for me to create reporting and dashboards that would have been difficult to build otherwise. The ease of creating dashboards with Grafana for accessing the data consumed by these processes is a notable advantage.

The integration of VictoriaMetrics has simplified my daily work by providing the ease of having time to create a relational database that allowed me to create tests with great ability in a short timeframe. I overcame the fact that I did not waste time standardizing the data. The speed, standardization, and small footprint with optimization of space allowed me to create test procedures in a very short time, which is certainly a significant advantage because I can create a product quickly.

The best features offered by VictoriaMetrics are that it is a very fast database and a time series database that is very capable of handling an enormous amount of data. This is exceptional.

I find the data compression particularly useful in my daily work, and I moved from Prometheus to VictoriaMetrics precisely because of the ability to have a larger amount of data in the same space, meaning secondary storage.

I consider the speed with which I can connect to this data compared to a relational database and the fact that it is an open-source platform particularly relevant. There is a community that allows me to eventually manage an open-source project without having to worry about the possibility of receiving updates.

The fact that it is open source is very important, and it integrates well with existing tools such as Prometheus or with connectors for data access from my services.

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.

I have been using VictoriaMetrics for a few months to create a monitoring system, and it is now in production, though not heavily used. I am still keeping it in test, but the company still does not want to take advantage of the results of my test.

VictoriaMetrics is absolutely stable according to my experience. I did not need to perform updates in the period between December and February of this year.

I have no experience with upgrading VictoriaMetrics and I have had no need for upgrades. At this time, I cannot go into detail.

I have not had the opportunity to interact with the support service of VictoriaMetrics.

I was using a different solution previously, which was a custom solution with a relational database, but the infrastructure required many more resources, so I had to think of an alternative.

I have implemented VictoriaMetrics in my organization using on-premises infrastructure.

I am still in the testing phase awaiting the company's evaluation, and therefore I have not yet progressed beyond the phase in which I can discuss a return or benefits.

My experience with the pricing, setup costs, and licensing of VictoriaMetrics is positive. I used the free open-source version, and it was sufficient for my needs.

Before choosing VictoriaMetrics, I went directly to Prometheus and then from Prometheus to VictoriaMetrics, also passing through Zabbix. However, I evaluated Zabbix as an alternative that was far less performant than what I needed.

On a scale from 1 to 10, I would rate VictoriaMetrics an 8.

I chose exactly 8 out of 10 because I do not have full knowledge of the product in production, and my experience stopped at the testing phase pending the company's evaluation.

Regarding the AI features of VictoriaMetrics, I did not have the opportunity to use them.

The advice I would give to other people who are considering using VictoriaMetrics is that it is a reliable product with few hardware resources required, so I recommend it.

My overall review rating for VictoriaMetrics is 8 out of 10.

VictoriaMetrics is a time-series database that we use to handle a large volume of metrics coming from our application. We have multiple applications running, and we want to monitor everything to understand exactly what is happening, so we deployed VictoriaMetrics to serve as our time-series database and then use Grafana to visualize the data. VictoriaMetrics serves as a replacement for Prometheus to monitor all the time-series data that comes from our applications.

VictoriaMetrics is built with memory constraints in mind, and we saved a significant amount of memory after implementing it. The first advantage is that it is quite easy to use, and we can leverage PromQL queries in VictoriaMetrics with a straightforward deployment process.

The best aspect of using VictoriaMetrics is the reduction in resources including RAM, memory, disk, and other infrastructure requirements, which have all decreased substantially after implementation.

We observed that RAM was reduced by around 70% and disk usage by 75%, while write speed increased 3x and query per second P95 latency became 7x faster. The financial savings are significant because we observed a substantial reduction in resources such as CPU and memory after adopting 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.

We have been using VictoriaMetrics for around two years.

VictoriaMetrics is stable.

VictoriaMetrics's scalability is quite good.

We use the open-source version of VictoriaMetrics, so we did not require any customer support. However, we do use the open-source project to contact them and learn more about the issues and projects that we are working on.

We used Prometheus earlier, but we found that the resource usage was quite high, so we decided to try VictoriaMetrics, which resulted in a substantial reduction in resources.

We did not require any license for VictoriaMetrics since we are using the open-source version, so the setup cost is what we incurred.

We did not require any license for VictoriaMetrics since we are using the open-source version, so the setup cost is what we incurred.

Prometheus was the solution we were using, and we did not evaluate other options; we simply proceeded with VictoriaMetrics and have continued to use it.

You should use VictoriaMetrics if you are currently using Prometheus, as I believe it is quite helpful and you should consider switching. I give this review an overall rating of 9.