VictoriaMetrics Cloud: Prometheus & OpenTelemetry metrics, logs, traces

My main use case for VictoriaMetrics is monitoring, capacity planning, and observability.

In my day-to-day work, we monitor CPU utilization and memory utilization associated with application tags. When a certain threshold is breached, we send out an alert to the team responsible for monitoring that particular application. This allows us to see in advance if the number of connections or users is growing, which helps us look at the trend over the past few months and plan in advance whether we need to increase our capacity, whether we need to scale by adding more nodes, or whether we need to scale vertically by adding more CPU or more RAM.

Regarding my main use cases with VictoriaMetrics, after getting all the metrics, we learned that our select and insert nodes were barely hitting any CPU and memory usage, and we had overprovisioned them, so we scaled them down to the right size and number. However, we also noticed that the storage nodes are the ones heavy on CPU and memory usage, so we scaled them up vertically and added many more nodes because we had been watching the trend and the disk space was constantly growing due to our organization's growth and increased logging. We could see the trend, reduce costs on the select and insert nodes that are barely used, and move that cost elsewhere, which is great.

Another specific example I can give is that we use VictoriaLogs for our logging infrastructure.

VictoriaMetrics has positively impacted my organization in that before it, we didn't really have much to identify alerts or look at short-term trends, and we struggled to pinpoint the cause of issues or at least what was happening when the system misbehaved. This has added a lot of value, including that alerts are simplified now because of VictoriaMetrics.

Incident detection has been faster, so rather than the team reaching out to us, we can see it before they reach out to us.

The best feature VictoriaMetrics offers is that from my observability point of view, it allows you to copy data across the same size node, so data is replicated, which is a really good feature, something that I think is missing in VictoriaLogs.

That replication helps my team day-to-day in that we have planned for situations where we were to lose an entire zone. We would be safe and able to use the data, and we can rely on VictoriaMetrics to use the data because we could replicate it across different zones, which helps us justify our high availability design for VictoriaMetrics.

Regarding the features of VictoriaMetrics, I think the standout is where you can send your query to a different node if data is missing on the one node where the full data set is available. We are actually using this feature and finding it very useful for the migration from the single node to the clustered environment while the data is being hydrated.

I think it would be beneficial to have monthly notifications regarding internal positions.

I have been using VictoriaMetrics for about a year and a half.

VictoriaMetrics is stable in my experience.

VictoriaMetrics's scalability is very stable and easy to scale.

VictoriaMetrics customer support is exceptional. We have used it now and then, and responses are very quick, and the solutions are usually worked through. I would rate the customer support for VictoriaMetrics a 10.

We did use Prometheus before switching to VictoriaMetrics. The motivation to switch was that VictoriaMetrics provided the cluster feature out of the box, whereas with Prometheus, we would have to put Thanos on top of it, which was a slightly more complicated setup.

I haven't seen a return on investment with VictoriaMetrics, as I'm not at that level to see ROI.

My experience with pricing, setup cost, and licensing for VictoriaMetrics is that I'm not involved with those parts. However, I can say it's also good judging by team memebers who dealt on those aspect.

Before choosing VictoriaMetrics, I only evaluated Prometheus.

I would rate VictoriaMetrics a 10, because it meets our expectations. Regarding VictoriaMetrics's AI capabilities, we haven't explored that feature yet, but it's good to know you have this feature.

The main scenario we tested during our proof of concept was against its competitors in the field, which are Thanos and Mimir.

We were looking into how it works with our existing infrastructure in terms of having already running Prometheus instances and how it works with remote write, which was one of our goals.

We also examined storage patterns and additional factors that were very relevant for us, such as downsampling, which was quite necessary to actually save on storage costs.

We evaluated it based on approximately 10 points. Those evaluation points included storage, how it queries, how it reads and writes, how it compacts, how it downsamples, how it supports multi-tenancy, which is also very important for us, and the query language.

VictoriaMetrics, or specifically VM agent, has positively impacted my organization because it allows us to feed metrics into our centralized metrics storage, which gives us visibility of our infrastructure.

I would not say the same about the overall impact in terms of differentiation.

Any other agent would give us the same visibility, and the VM agent simply does it with less resource usage.

Out of those evaluation points, the thing that really stood out to me about VictoriaMetrics compared to the others was that it was the least resource-intensive.

For a larger scale, you would really save on resources and compute power.

The selection of VictoriaMetrics-related items, not VictoriaMetrics storage and metrics backend itself, is actually very impressive.

We currently use VM agent, which is VictoriaMetrics agent, as one of our main ways to get metrics from our environments to our final storage.

The product itself has some negatives.

It is very enterprise-oriented, in my opinion.

The storage is not the best in my view.

The local and block disks that it had when we tested it was neither particularly bad nor particularly good, in my opinion.

Object storage and S3-like storage is something that is basically a company and industry standard now.

However, it was good on resources and it did not do things how we wanted, so we landed on something different.

We still use VictoriaMetrics agent to deliver metrics from our multi-tenancy, multi-region clusters to one centralized object storage.

In my experience, the best features VictoriaMetrics offers include that VM agent does its work very efficiently and does not use a lot of resources.

It supports all of the relevant Prometheus-like scrape configs, so you can manage the labels and relabel things before writing or sending them.

It does everything well, and due to the resource usage, it does it the best in our opinion.

In addition to that, we also run it in quite an unusual pattern.

We have three zones in one of the clusters, and what helps us is ensuring that we get all the metrics from the relevant zones without any duplicates.

We also run in parallel a zoneless setup, which allows us to quickly switch if, for example, the zones are not working correctly.

This gives us replication factors so that we never lose our metrics.

Most of all, I value the VM agent for the resource efficiency and because it supports all of the common scrape, relabel, and all of the other necessary operational jobs so that you actually get your metrics with valuable labels.

I am sad that VictoriaMetrics moves towards enterprise only for features that it is really good at, such as downsampling.

Hopefully this product keeps on improving on the basis of VM operators and VM agents, and from there, moves toward less enterprise and more open source with fewer features gated behind enterprise prices.

VictoriaMetrics needs to be less enterprise-gated and more open source, allowing people to actually experience full scalability and the full feature set without being forced to pay enterprise prices, get quotes, or pay for licenses.

I do not remember the exact enterprise gate that prevented us from using certain features, but I remember that we could not enable some of the features and use it efficiently because there was no downsampling.

We really needed it because it is what saves on storage costs.

Other than that, I would encourage continuing to improve what already exists.

We have not been using VictoriaMetrics per se.

We did conduct quite an extensive proof of concept for three options: Thanos, Mimir, and VictoriaMetrics.

In terms of how long I have been using similar applications, it would be around three to five years, actually owning them and configuring them end to end.

I can share insights regarding that experience.

VictoriaMetrics stores metrics and when you query it, it gives you metrics.

It should be quite accurate and reliable if the metrics have been stored correctly.

The resource efficiency of VictoriaMetrics allows you to reduce infrastructure costs.

The advice I would give to others looking into using VictoriaMetrics is to always run your proof of concepts and test other storage backends such as Thanos and Mimir.

I would rate VictoriaMetrics a four out of ten.

I chose a four out of ten because it simply finished last in our proof of concept, so there is no reason to rate it higher.

Even the solution that we use now does not receive a ten out of ten.

It finished last because of the enterprise gate mostly.

My main use case for VictoriaMetrics is high availability cluster configuration for long-term Prometheus metric storage.

A specific example of how I'm using VictoriaMetrics in my environment is that we collect metrics from infrastructure, from application, and from Kubernetes environments.

One thing I really appreciate about using VictoriaMetrics for this is that it serves as a metrics replacement for Prometheus in usual scenarios.

The best features VictoriaMetrics offers are performance and high availability.

VictoriaMetrics delivers on performance and high availability for me by being quicker than Prometheus, and since Prometheus delivers no high availability, using VictoriaMetrics cluster configuration split into different data centers makes our VictoriaMetrics cluster configuration highly available.

VictoriaMetrics has positively impacted my organization as it is a stable, performant, safe, and well-engineered piece of software which works exactly as expected and delivers stable results.

I cannot share any specific outcomes or metrics that show the positive impact as I cannot express it in measured values.

I believe that VictoriaMetrics can be improved by having a new user interface which could automatically cross-link OpenTelemetry data types such as metrics, logs, and traces in a single UI available both for agents and users. My focus of interest is on OpenTelemetry, and I hope that VictoriaMetrics will deliver on OpenTelemetry improvements on semantic conventions and unification of queries for different data types using the semantic conventions.

I strongly believe that VictoriaMetrics should be more OpenTelemetry compatible. It should not just be compatible, but OpenTelemetry should be a first-level citizen native to any VictoriaMetrics backends and convenient, not a strange type of Prometheus metric. OpenTelemetry metrics, traces, and logs should be convenient for use, specifically with the things which differentiate OpenTelemetry from non-OpenTelemetry data types.

I suggest that you take a closer look at the Google command line interface for agents, GCX, and it may be worth implementation in VictoriaMetrics because it could save a lot of effort for users and agents, improve accuracy of AI queries, improve quality of answers, and decrease token usage.

I have been using VictoriaMetrics for four years.

The accuracy and reliability of the output I get from VictoriaMetrics are quite accurate and reliable, and I have nothing to criticize.

VictoriaMetrics is stable for me.

My experience with VictoriaMetrics's scalability is that it is perfect.

I do not use customer support, but I know that it is good.

Before VictoriaMetrics, I used Prometheus.

I decided to switch from Prometheus to VictoriaMetrics due to high availability and performance.

I cannot share a return on investment from using VictoriaMetrics. However, in my case, the benefits I have noticed include some savings on less downtime, smoother upgrades, and less interruption due to server upgrades.

My experience with pricing, setup cost, and licensing is minimal, as I use the open-source version, so I do not know anything about pricing, licensing, or setup cost.

Before choosing VictoriaMetrics, I did not evaluate other options.

I rate VictoriaMetrics overall as a ten out of ten because it works exactly as intended.

Regarding VictoriaMetrics's AI capabilities, if we are talking about the enterprise version, I believe it should work there, but I do not use enterprise VictoriaMetrics. I do not have information about VictoriaMetrics AI.

VictoriaMetrics is deployed in my organization on-premises, but we have a large instance deployed into a private cloud.

For my private cloud deployment, I use Google GCP.

I do not have general advice to give to others looking into using VictoriaMetrics.

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.