VictoriaMetrics Reviews

VictoriaMetrics' main use case for our AI platform is scalable, long-term Prometheus-compatible metric storage, a drop-in replacement for Prometheus, Thanos, and Cortex that handles high ingest rates and cardinality with less operational overhead.

My main use case involves transitioning from closed, air-gapped environments to open international infrastructures with a strong AI/ML focus. I aim to leverage my experience in CI/CD, containerization, and cloud platforms to contribute to more dynamic and scalable systems. My background in migrating legacy systems to Kubernetes and working with MLOps tools positions me well for growth in AI/ML-driven environments.

The fast query performance of VictoriaMetrics allows engineers to use dashboards effectively for monitoring and incident analysis. Efficient resource usage has reduced operational overhead, letting the team focus on improving the platform. The reliable metrics history enabled better capacity planning and faster problem detection. Overall, it improves productivity and ensures consistent, high-quality monitoring.

VictoriaMetrics has positively impacted my organization by significantly reducing our storage costs and improving query performance. It allows us to scale horizontally, handle large volumes of metrics efficiently, and integrate seamlessly with our existing Prometheus setup. We have seen a 40% reduction in memory usage and faster query response times, which has enhanced our monitoring reliability and operational efficiency.

Regarding storage cost reduction, VictoriaMetrics uses strong compression, reducing disk usage by 80% compared to raw metrics. Regarding query speed, queries on old data are fast due to local disk access, often 10 times faster than object storage-based systems. For cost reduction, using local disks instead of S3 can cut storage costs by 50-70%, depending on data volume and retention.

The best features VictoriaMetrics offers in my experience include fast query performance and efficient resource usage, seamless compatibility with the Prometheus ecosystem, a simple cluster architecture with minimal components, MetricsQL with useful functions beyond PromQL, and comprehensive tooling like VMAgent and VMAlert.

VictoriaMetrics stands out to me because it is highly efficient, stable, and easy to run in air-gapped environments. It integrates well with Prometheus ecosystem tools like Kube-Prometheus-Stack and Grafana. Its compact storage and fast query performance make it ideal for long-term metric storage. The cluster setup is simple and scalable, which is a big advantage for production use.

I see minor improvements needed for VictoriaMetrics, such as automatic rebalancing and addressing the large ecosystem. Some features are only available in the Enterprise edition. I suggest starting with remote write for low-risk migration and planning labels and cardinality upfront to avoid issues.

The main areas of improvement for VictoriaMetrics include automatic rebalancing, a large ecosystem, and Enterprise features. I faced challenges during the initial setup and ensuring proper label management to avoid cardinality issues. Overall, VictoriaMetrics is reliable and meets all my needs effectively.

I have been using VictoriaMetrics for about two years in production, primarily as a long-term storage and query engine for our AI platform.

VictoriaMetrics has been stable in my experience. The components are simple, restarts are fast, and stateless parts can be replaced without data loss. I use replication, backups, and monitoring to ensure reliability.

VictoriaMetrics scales horizontally with its cluster model, allowing easy expansion as data grows. It handles large volumes of time series data efficiently, using less memory and disk compared to Prometheus or Thanos. The remote write integration ensures simple scalability without changing existing Prometheus setups.

I do not have personal experience with customer support for VictoriaMetrics, but the project is actively maintained and has a strong community, which can be a good resource for support and troubleshooting.

I previously used Prometheus before switching to VictoriaMetrics. I made the switch because VictoriaMetrics provides better long-term storage, improved query performance, and easier horizontal scaling, which we needed for our platform with many GPU nodes and a large number of time series. It also integrated simply with the Prometheus ecosystem, allowing minimal changes to our existing setup.

I found the transition from my previous solution to VictoriaMetrics to be smooth by using remote write and parallel running. There was no data loss, and I am grateful for VMCTL for old data migration. I adjusted Grafana and alerts gradually, with minimal risk due to careful planning and testing.

VictoriaMetrics is deployed as a cluster in our organization, running on-premises integrated with Kubernetes. We use Kube-Prometheus-Stack for metrics collection, and Grafana and Alertmanager are also on-premises for visualization and alerts.

I have seen a return on investment with VictoriaMetrics, saving 40% in storage costs compared to Prometheus, reducing query latency by 60%, and cutting maintenance time by half. There is no need for additional staff due to its simpler setup and management.

My experience with pricing, setup cost, and licensing for VictoriaMetrics is positive since it is open-source under Apache 2.0, so there is no licensing cost. The setup is straightforward, and infrastructure costs are lower due to its efficiency. I encountered no major setup hurdles.

Before choosing VictoriaMetrics, I evaluated other options such as Prometheus for long-term storage and Thanos. However, VictoriaMetrics offered better query performance, more efficient storage, and easier horizontal scaling. It integrated seamlessly with the existing Prometheus ecosystem, making the transition smoother.

I would rate VictoriaMetrics a nine out of ten because it is fast, efficient, and integrates well with the Prometheus ecosystem, making it ideal for long-term storage and scalable setups. The only minor drawbacks are its ecosystem size and some Enterprise features. I choose nine out of ten for VictoriaMetrics because it is fast, efficient, stable, and integrates well with Prometheus. A perfect ten would require no minor improvements, such as better automatic rebalancing and a larger ecosystem.

I do not have direct experience with VictoriaMetrics' AI capabilities. Regarding governance and security, I focus on securing the deployment using Kubernetes network policies, VMAuth for authentication, and TLS while managing secrets via secure stores such as Vault. I also ensure proper tenant isolation and access control.

My advice for others looking into using VictoriaMetrics is to start with remote write from your existing Prometheus to minimize risk. Plan labels and cardinality upfront. Set up monitoring and alerts for VictoriaMetrics, keep regular backups, and test restores. Choose single-node or cluster based on real scale, not trends. I rate VictoriaMetrics at nine out of ten overall.

My main use case for VictoriaMetrics is monitoring and collecting data from a Kubernetes cluster, especially logs and traces, to understand application failures and application performance.

For example, after deploying an application with some changes, the new application went live, and I was able to see in the logs exactly what was happening there. In terms of the application's performance, I was able to see the consumption metrics, including memory consumption, data consumption, and network consumption. Since the deployment included fixes, I was able to see in the logs whether those fixes were applied in the application or not. VictoriaMetrics allows me to do all those things.

I use almost everything that VictoriaMetrics has to offer in my environment, but I do it with the open-source version. I use it for performance monitoring, database monitoring, logging, and application traces.

VictoriaMetrics positively impacts my organization by allowing me to do monitoring in a very easy way. I came from Prometheus, which was very similar for me. The switch to VictoriaMetrics has been very seamless, and I have seen the benefits of it in terms of performance. The usage of the cluster has reduced, and the query performance is faster. Additionally, I see that VictoriaMetrics comes with anomaly detection, which I plan to try out as well.

I can say that the usage is at least 30% more efficient compared to Prometheus. Because it is more efficient, the query performance is much faster.

One of the best features that VictoriaMetrics offers is that it is a time-series database, which is a like-for-like replacement for Prometheus. Since I originally came from Prometheus, VictoriaMetrics is more of an optimized version of that. It works much better, is more reliable, and is simpler and more efficient to work with. Additionally, there is a logging solution, so I am able to see logs of the application.

When comparing VictoriaMetrics to Prometheus, I saw that Prometheus itself was a bit heavy to use. With VictoriaMetrics, the query performance is faster, and it requires a lesser amount of storage space as well. Since I have deployed it on the cloud, it is scalable because it comes with Docker images which I deploy using Kubernetes. It has reduced memory usage and faster query performance.

Regarding pricing, because I am using the open-source version, it does not impact me too much. However, for people who want to go into the enterprise version, I think VictoriaMetrics needs to work on the pricing because it is quite high even if someone uses a single cluster. It is quite expensive. Otherwise, it is a very evolved product with not a lot of scope for improvement. I would say maybe more integration with the agents would be beneficial, so that it can work on its own one day.

Regarding needed improvements, I am happy with whatever I am getting from VictoriaMetrics.

I chose 9 out of 10 because it is very similar to Prometheus. Other than the performance improvements, VictoriaMetrics needs to add more features to differentiate itself from the market. That is one thing they can improve upon.

I have not noticed any other improvements needed with VictoriaMetrics that I have not discussed yet.

I have been using VictoriaMetrics for around four years.

VictoriaMetrics is very stable in my experience.

VictoriaMetrics is extremely scalable because it is deployed on the cloud, on Kubernetes, and I just need to increase the scale as needed.

However, there is a lot of community support available.

I used Prometheus before using VictoriaMetrics, and Prometheus was a bit heavy. It lagged a little bit in terms of performance and was not as optimized as VictoriaMetrics.

I have seen a lot of improvement in terms of time saved. Because VictoriaMetrics runs more efficiently and much faster, debugging an issue or understanding system performance is much easier. I do not have a number to share, but I have definitely seen a lot of improvement in terms of performance and the time taken to resolve issues.

However, I do see the pricing online, and it is a bit on the pricier side.

I came from another organization where I had used VictoriaMetrics, and I knew that I needed to change to this solution.

I would rate VictoriaMetrics 9 out of 10.

Regarding VictoriaMetrics's AI capabilities, governance, and security, I am not using it right now, but I do see that VictoriaMetrics has come up with an anomaly detection module, which provides observability with AI. I am looking forward to using that, but I think it comes with enterprise plans only, and I am on the open-source version.

Based on my experience, I expect VictoriaMetrics's accuracy and reliability of output to be on par with other tools in the market, such as Dynatrace. Their accuracy is very good, and more than 90% of the time, they give me the correct result. VictoriaMetrics should not be lagging behind and should reach that target.

I deploy VictoriaMetrics in my organization using public cloud. I use Azure as my cloud provider.

If you are coming from Prometheus, I recommend going for VictoriaMetrics. It is way better than Prometheus and customizable as well, similar to what Prometheus offers, but with better performance and efficiency.

My main use case for VictoriaMetrics is collecting logs and visualizing them, ensuring all resources are in good health, and verifying that no logs are being missed while not using a lot of space and resources for log management or visualizations.

A specific example of how I use VictoriaMetrics for log management and visualization comes from my prior experience with other metrics such as the ELK stack, Splunk, and ChaosSearch. All I required from VictoriaMetrics was to provide the same functionality but be faster, less resource-hungry, and have a smaller footprint on memory and disk space without sacrificing any efficiency.

I would say that we rely on VictoriaMetrics as a faster, cheaper, and more efficient solution compared to the other heavy technology stacks that are available.

VictoriaMetrics has positively impacted my organization because it was faster to implement, it has a simplistic interface and deployment, and the storage integration and other aspects were robust.

After switching to VictoriaMetrics, we reduced things by approximately half for our clients in terms of specific improvements including time saved, cost reduction, and fewer resources needed.

The best features VictoriaMetrics offers in my experience are light-speed querying and remote storage, along with very fast data ingestion that feels simple to use.

The light-speed query feature has made a significant difference for me because when we query, it is much faster in VictoriaMetrics compared to the other tools we had used previously. When using remote storage, especially when we are trying to use Prometheus and want to keep it in the most compact form, VictoriaMetrics performs very well.

Although I have not used much of the AI part of VictoriaMetrics, from what I have observed, I believe it has promising capabilities regarding governance and security.

We have not yet trained the AI capabilities or had extensive usage with it, but we have used it to query and build some queries, and so far it has been very straightforward with no problems.

VictoriaMetrics integrates very nicely with Prometheus and other tools; with all the other tools we have, it was a drop-in solution.

For the use cases I have been involved in, there is nothing that I feel is not good; it exceeded our expectations and was far superior to the others.

At this moment, there are no improvements I see needed for VictoriaMetrics. For our use cases, it is a really good offering, and while we would be interested to see what else it brings in the future, at this point in time it checks all our boxes and we are quite satisfied with it.

I have been using VictoriaMetrics for almost six months to a year.

In my experience, VictoriaMetrics has been stable with no downtime or reliability issues.

I have found that it is easy to scale both up and out with VictoriaMetrics as our data grows. We have not had transformational scaling yet, and so far the scaling has been controlled, but we will have to see if it scales significantly in the future.

VictoriaMetrics has handled increases in data and users smoothly so far; it has scaled nicely for the sustained growth we have experienced, and we have not had very high spikes.

My experience with customer support for VictoriaMetrics has been positive. We reached out once or twice for minor issues during the initial setup and integration, and they were helpful in resolving the issues.

We and other clients of ours had used Splunk, ChaosSearch, and other tools before switching to VictoriaMetrics.

The integration process with our existing systems was smooth.

One of our clients had already purchased VictoriaMetrics, but we optimized the usage, implemented it, and set it up.

In terms of return on investment, there is a bit of everything involved. Money was saved by at least 30 to 40%, we have the same employees so that might not factor in since they were there with other tools as well, and time was saved due to simplicity and a shorter learning curve compared to other tools.

I was not directly involved in the financial processes related to pricing, setup cost, and licensing for VictoriaMetrics, but based on what our clients have purchased based on my recommendations, it seemed reasonable.

We simply switched to VictoriaMetrics after evaluating other options, considering that price was a factor along with the footprint of storage. VictoriaMetrics stood out to us, so we made the switch.

My advice for others looking into using VictoriaMetrics is to definitely try it out on their development stack to really experience its power before switching to production, as it depends on their scale and deployments. So far, we have found it looks very good.

For our hybrid deployment, we use AWS and OpenStack.

I rate VictoriaMetrics a perfect 10 out of 10 because I could not think of anything else that others offer that VictoriaMetrics does not have. Even though VictoriaMetrics is smaller compared to competitors, it would not be fair to rate it down solely because of scale. I considered scale and reputation, but VictoriaMetrics still deserves a perfect rating.

My main use case for VictoriaMetrics is storing and querying infrastructure metrics in my SmartOps observability project, which include CPU, memory, latency, and error rates. Metrics flow through Kafka into VictoriaMetrics, then feed Grafana dashboards, VM Alert rules, and an anomaly detection workflow that uses the data to investigate incidents.

VictoriaMetrics fits into my SmartOps project's anomaly detection workflow by providing the metric history for detection and investigation. The detector queries the last 10 minutes of data using PromQL, compares the latest values against a baseline, and flags unusual deviation or critical thresholds, for example, CPU usage reaching 85%. Once an anomaly is detected, an AI workflow correlates it with logs and distributed traces from the same region and time window. It can also query related metrics from VictoriaMetrics to investigate whether a CPU spike coincides with rising latency or errors, then suggest a likely cause and next steps. The initial detection uses statistical checks, and the AI helps interpret the evidence.

The impact of VictoriaMetrics has been at the project level. It gives SmartOps a shared metrics store for dashboards, alerting, and anomaly investigation, simplifying integration and making it easier to connect a detected spike with its historical context.

One example where using VictoriaMetrics made a difference in my project is the simulated CPU spikes in SmartOps. It provides the recent metric history so the detector can compare CPU usage with its baseline and flag the spike. The investigation workflow then correlates that event with logs and traces from the same region and time window, bringing the metric evidence into the investigation automatically and reducing the manual work of gathering context. Since this was a project simulation, I haven't measured time saving or validated the benefit during a production incident.

The standout features VictoriaMetrics offers are Prometheus compatibility, straightforward deployment, and efficient storage. The compatible query API made connecting Grafana and building the anomaly detection queries straightforward, while the single-node setup was easy to get running. Compression and resource efficiency are strong points, although I haven't benchmarked those myself. I also value VM Alert, which supports alerting, recording rules, and integrates with Alertmanager. In SmartOps, having dashboards, alert rules, and the investigation workflow query the same metric history is particularly useful.

If I had to pick one feature as the most valuable for my daily work, it would be Prometheus compatibility. In SmartOps, it allows me to use familiar PromQL queries across Grafana dashboards, alert rules, and the anomaly detection workflow, which saves integration effort and makes it easier to investigate an incident using the same metrics across those tools. It reduced the work needed to connect everything. I can query VictoriaMetrics through the Prometheus-compatible API, display the data in Grafana, and use familiar PromQL in alert rules and anomaly detection. That allows me to spend more time investigating what the metrics mean and less time writing integration code.

These features are particularly useful together. In SmartOps, Grafana, VM Alert, and the anomaly detection workflow all use the same metric history, making it easier to move from spotting a problem on a dashboard to investigating what happened.

From my project experience, I would appreciate more practical guidance on tuning queries and diagnosing missing or delayed metrics across the ingestion pipeline. When data passes through Kafka before reaching VictoriaMetrics, tracing where a gap starts takes some work. A clearer guide for moving from a single-node setup to a production cluster would also help, especially around sizing, retention, and availability. Those are areas where I would value more guidance as the project grows.

I would add more examples of handling sparse or delayed data in anomaly detection, such as how to distinguish a genuine metric change from an ingestion gap. That is partly an application design challenge, but practical guidance would help.

I have been using VictoriaMetrics for a few months.

VictoriaMetrics has been stable in my local SmartOps setup.

For SmartOps, the single-node setup has been sufficient. Having a cluster deployment option gives it room to grow.

For my project, I have relied on the documentation.

SmartOps started with VictoriaMetrics, so there was not a migration from another solution. I chose it for its Prometheus compatibility, straightforward single-node deployment, and integration with Grafana and alerting.

For my SmartOps project, VictoriaMetrics is deployed in a local, self-hosted Docker setup on my development machine. Of those options, on-premises is the closest fit, though it is a development environment rather than an organizational production deployment.

The clearest benefit is less manual work gathering metric history for anomaly investigations.

I used the open-source single-node edition locally, so there was no software license fee. The setup cost was mainly my time configuring Docker, ingestion, Grafana, and alerting.

I considered Prometheus with remote storage and InfluxDB but didn't run a formal benchmark comparison. I chose VictoriaMetrics for its Prometheus-compatible API and straightforward single-node setup, which suited SmartOps.

I would rate VictoriaMetrics eight out of ten.

I chose eight out of ten because it has been straightforward to deploy and integrates with Grafana, alerting, and my anomaly detection workflow. Prometheus compatibility is the biggest plus for me, and I rate it that way because my experience has been positive, but it is limited to a single-node project setup. I would want more production experience before rating it higher.

In SmartOps, the AI workflow sits in the application layer and queries VictoriaMetrics for metric data. Before using that in production, I would assess access controls, audit logging, and what data is sent to the AI provider.

In SmartOps, it supplies the metric data, while a separate AI workflow interprets it. I treat those AI explanations as hypotheses to check against metrics, logs, and traces.

I would suggest starting with a single-node setup and your actual metrics workload. Check that your Grafana dashboard and PromQL queries behave as expected, then monitor ingestion, query latency, memory, and storage usage. Pay attention to label cardinality and retention early. Before production, validate backups and recovery, access controls, and whether you need a cluster.

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.

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.

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.

My main use case for VictoriaMetrics is collecting metrics and storing them. These are metrics from various systems, both business metrics and infrastructure metrics describing how the system is performing. I collect them using exporters. This is basically the standard use of VictoriaMetrics for storage.

The best features that VictoriaMetrics offers are a sensible approach to storage. A targeted approach to storing large amounts of data, as well as convenient formation of storage clusters, seem most successful and useful to me.

VictoriaMetrics has positively impacted my organization because we were able to save on metric storage by not using expensive solutions from other vendors. I estimate the savings to be around ten to fifteen percent.

I would like to add aggregated storage as a general capability. I would prefer to store raw data for a shorter period of time and aggregated data for a longer period, particularly in cases where a high degree of accuracy is not required over a long distance.

Adding AI-based analysis could be beneficial, but that is more of a future consideration. There is room to grow in terms of data management and security capabilities, and I believe there is significant potential in these areas.

I started using VictoriaMetrics around 2022, so I have been working with it quite closely for the last four years.

Regarding stability, I would rate it a ten out of ten. There were no reliability issues.

With the necessary infrastructure in place, I see no problems with scalability in VictoriaMetrics.

I used Prometheus and also Thanos before deciding to move to VictoriaMetrics because it allowed me to achieve better results.

Before choosing VictoriaMetrics, I considered other options including Prometheus, Cortex, and Grafana's storage.

I rate VictoriaMetrics an eight out of ten. The reason I rate it eight is that the solution lacks aggregation and I have to either use a custom solution or solutions from other vendors.

The accuracy and reliability of the results that VictoriaMetrics provides when working with artificial intelligence are sufficiently accurate and reliable. My advice for those considering implementing VictoriaMetrics is to carefully assess the necessity of implementation.

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.

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.