Sold by: Victoria Metrics
Deployed on AWS
Simple, reliable, and efficient observability for everyone. VictoriaMetrics Cloud is a fully managed solution for metrics and logs. Run VictoriaMetrics and VictoriaLogs on AWS without the DevOps overhead. Cost-efficient time series and logging databases built on our scalable open-source products, with added enterprise features (downsampling, retention filters) and support from the engineers who build VictoriaMetrics. Guided integrations with Kubernetes, Grafana, Perses, Prometheus, OpenTelemetry, AWS CloudWatch, Fluentbit, and more.
4.4
Overview
Simple, efficient, reliable observability - fully managed on AWS.
Collect, store, and query metrics, logs, and traces without spending your time operating the observability infrastructure behind them.
VictoriaMetrics Cloud brings VictoriaMetrics, VictoriaLogs, and VictoriaTraces to AWS as a fully managed service. Get the performance and efficiency of VictoriaMetrics with automated operations, maintenance, upgrades, and backups handled by the team that builds it.
Spend less time operating observability. More time using it.
Whether you're scaling Prometheus, managing growing log volumes, adding distributed tracing, or looking for a more efficient observability architecture, VictoriaMetrics Cloud gives you purpose-built solutions for every signal without forcing everything into one database.
Ideal for:
- Managed Prometheus: scale beyond the operational limits of self-managed Prometheus.
- Long-term metrics storage: retain Prometheus data efficiently without managing the storage infrastructure yourself.
- Global metrics visibility: query metrics collected across environments and sources from one place.
- Managed logs: ingest, store, and search logs with VictoriaLogs.
- Managed distributed tracing: ingest and investigate traces with VictoriaTraces to understand how requests move across services and where latency or errors occur.
- OpenTelemetry environments: ingest telemetry using OpenTelemetry, including OTLP for distributed traces.
- Metrics, logs, and traces: run purpose-built solutions for each telemetry signal within one managed VictoriaMetrics Cloud service.
Why VictoriaMetrics Cloud?
Observability shouldn't require another infrastructure team to operate it.
VictoriaMetrics Cloud removes the work of configuring, monitoring, securing, updating, scaling, and backing up your observability infrastructure. Every deployment runs in an isolated environment and can scale as your requirements change.
You get the VictoriaMetrics solutions you already know, operated and supported by the engineers who build them.
How does it work?
Create a deployment in VictoriaMetrics Cloud and connect your existing telemetry sources.
For metrics, point Prometheus, vmagent, or the OpenTelemetry Collector to your VictoriaMetrics Cloud endpoint.
For logs, ingest data using supported integrations, including OpenTelemetry and Fluent Bit.
For traces, send distributed tracing data using OpenTelemetry Protocol (OTLP) to VictoriaTraces, where traces can be stored, searched, and used to investigate application behavior across distributed services.
Continue using familiar tools such as Grafana while VictoriaMetrics manages the infrastructure behind your deployment.
Built for engineers who would rather use observability than operate it.
- Managed metrics with VictoriaMetrics
- Managed logs with VictoriaLogs
- Managed distributed tracing with VictoriaTraces
- OpenTelemetry support
- Isolated deployments
- Easy scaling
- Automated backups and maintenance
- Alerts and notifications
- Enterprise features included
- Expert support from the VictoriaMetrics team
VictoriaTraces availability
VictoriaTraces is now available in VictoriaMetrics Cloud as a fully managed, single-node deployment with secure OTLP/HTTP ingestion and built-in trace exploration. This version does not include high availability or OTLP/gRPC ingestion.
Start with VictoriaMetrics Cloud on AWS.
Move your metrics, logs, and traces without taking on another observability infrastructure project.
Highlights
- Simple: fully managed metrics and logs with no configuration, scaling, updates, or backups to run yourself.
- Reliable: isolated instances, automated backups and alerts, and support from the engineers who build VictoriaMetrics.
- Efficient: handle bigger workloads at far lower cost, pay only for the compute you actually use, with predictable budgeting.
Details
Sold by
Categories
Delivery method
Deployed on AWS
New
Introducing multi-product solutions
You can now purchase comprehensive solutions tailored to use cases and industries.
Features and programs
Buyer guide
Gain valuable insights from real users who purchased this product, powered by PeerSpot.
Financing for AWS Marketplace purchases
AWS Marketplace now accepts line of credit payments through the PNC Vendor Finance program. This program is available to select AWS customers in the US, excluding NV, NC, ND, TN, & VT.
Pricing
Pricing is based on the duration and terms of your contract with the vendor, and additional usage. You pay upfront or in installments according to your contract terms with the vendor. This entitles you to a specified quantity of use for the contract duration. Usage-based pricing is in effect for overages or additional usage not covered in the contract. These charges are applied on top of the contract price. If you choose not to renew or replace your contract before the contract end date, access to your entitlements will expire.
Additional AWS infrastructure costs may apply. Use the AWS Pricing Calculator to estimate your infrastructure costs.
Dimension | Description | Cost/month |
|---|---|---|
VictoriaMetrics Cloud | Pay-as-you-go pricing - no subscription fee | $0.00 |
Dimension | Description | Cost/unit |
|---|---|---|
Usage - Detailed pricing information available in VictoriaMetrics Cloud | Detailed pricing information based on usage available in VictoriaMetrics Cloud | $1.00 |
Dimensions summary
This listing uses pay-as-you-go pricing with no subscription fee. You are not charged a fixed amount upfront. Instead, charges accrue based on your actual usage inside VictoriaMetrics Cloud. Cost per deployment comes from three parts: compute, storage, and network egress. You pick a capacity tier for compute and a storage amount, each with a fixed cost shown before you confirm. Network egress is charged per GB. Usage accumulates hourly and is billed monthly. Through AWS Marketplace, charges can be consolidated into your AWS bill. Detailed per-tier pricing appears when you create a deployment in the application.
Top-of-mind questions for buyers
Each deployment has three cost parts. Compute covers the capacity tier you select, with a fixed cost. Storage covers the disk you choose, also fixed. Network covers external egress traffic, charged per GB. Compute and storage are shown before you confirm. Network is the only variable part.
Compute and storage drive most of your cost. You pick a capacity tier and disk size, each with a fixed price. Network egress is typically below 0.5% of the total, even for large deployments. All three charges appear together on your monthly invoice.
Usage is metered per hour and charges apply monthly at period end. Each deployment has predefined limits that protect you from unexpected overages from ingestion spikes or heavy queries. You can scale compute or storage up or down in a few clicks, with the exact new cost shown before you confirm.
docs.victoriametrics.com+1
Helpful?
Vendor refund policy
All fees are non-cancellable and non-refundable except as required by law.
Legal
Vendor terms and conditions
Upon subscribing to this product, you must acknowledge and agree to the terms and conditions outlined in the vendor's End User License Agreement (EULA) .
Content disclaimer
Vendors are responsible for their product descriptions and other product content. AWS does not warrant that vendors' product descriptions or other product content are accurate, complete, reliable, current, or error-free.
Delivery details
Software as a Service (SaaS)
SaaS delivers cloud-based software applications directly to customers over the internet. You can access these applications through a subscription model. You will pay recurring monthly usage fees through your AWS bill, while AWS handles deployment and infrastructure management, ensuring scalability, reliability, and seamless integration with other AWS services.
Resources
Vendor resources
Support
Vendor support
Check how to reach support at VictoriaMetrics Cloud docs .
Alternatively, send an email to support-cloud@victoriametrics.com
AWS infrastructure support
AWS Support is a one-on-one, fast-response support channel that is staffed 24x7x365 with experienced and technical support engineers. The service helps customers of all sizes and technical abilities to successfully utilize the products and features provided by Amazon Web Services.
Updated weekly
Sentiment is AI generated from actual customer reviews on AWS and G2
Functionality
Ease of use
Customer service
Cost effectiveness
Positive reviews
Mixed reviews
Negative reviews
AI generated from product descriptions
Time Series Database
Cost-efficient time series database built on scalable open-source VictoriaMetrics with support for long-term Prometheus data retention and efficient storage without manual infrastructure management.
Log Ingestion and Storage
Managed log ingestion, storage, and search capabilities through VictoriaLogs with support for OpenTelemetry and Fluent Bit integrations.
Distributed Tracing
Fully managed distributed tracing with VictoriaTraces supporting OpenTelemetry Protocol (OTLP/HTTP) ingestion for trace storage, search, and investigation across distributed services.
Multi-Signal Observability
Purpose-built solutions for metrics, logs, and traces operating within a single managed service with OpenTelemetry support for unified telemetry collection.
Enterprise Data Management
Enterprise features including downsampling and retention filters for optimized data storage and query performance.
Time-Series Data Collection and Storage
Collects and stores time-series metrics from various sources including applications, servers, containers, and cloud services
Flexible Alerting Rules
Supports flexible alerting rules to proactively detect and respond to abnormal or critical conditions
Interactive Dashboard Visualization
Provides interactive dashboards for visualization and analysis of metrics with trend tracking and anomaly identification capabilities
Integration with Monitoring Tools
Seamlessly integrates with monitoring and visualization tools such as Grafana to enhance data analysis capabilities
Scalable Architecture
Designed with scalable architecture to handle large-scale deployments suitable for cloud-based environments and dynamic infrastructures
Application Performance Monitoring
Monitors application performance metrics, traces, and errors across the entire software stack with integrated APM capabilities.
Infrastructure and Log Monitoring
Provides infrastructure monitoring, log management, and analysis with centralized ingestion of metrics, events, logs, and traces in a single platform.
Anomaly Detection and AIOps
Automatically detects anomalies, correlates issues, and reduces alert noise using built-in AIOps capabilities across all monitoring data.
Multi-Source Telemetry Integration
Integrates telemetry data from AWS services including EKS, Lambda, Kinesis, CloudWatch, DynamoDB, and supports OpenTelemetry instrumentation, Prometheus OpenMetrics, and Pixie auto-telemetry for Kubernetes.
Pre-built Integration Library
Includes over 500 quickstart integrations for rapid deployment and monitoring configuration across various technologies and services.
Standard contract
No
Customer reviews
Adil-Siddiqui
Monitoring has become faster and simpler while log storage and query performance improve
Reviewed on Oct 16, 2026
Review from a verified AWS customer
What is our primary use case?
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.
How has it helped my organization?
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.
What is most valuable?
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.
What needs improvement?
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.
For how long have I used the solution?
I have been using VictoriaMetrics for almost six months to a year.
What do I think about the stability of the solution?
In my experience, VictoriaMetrics has been stable with no downtime or reliability issues.
What do I think about the scalability of the solution?
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.
How are customer service and support?
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.
Which solution did I use previously and why did I switch?
We and other clients of ours had used Splunk, ChaosSearch, and other tools before switching to VictoriaMetrics.
How was the initial setup?
The integration process with our existing systems was smooth.
What about the implementation team?
One of our clients had already purchased VictoriaMetrics, but we optimized the usage, implemented it, and set it up.
What was our ROI?
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.
What's my experience with pricing, setup cost, and licensing?
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.
Which other solutions did I evaluate?
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.
What other advice do I have?
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.
Which deployment model are you using for this solution?
Hybrid Cloud
If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?
Amazon Web Services (AWS)
reviewer2910642
Enterprise limits have restricted cost savings but resource‑efficient metrics collection has helped
Reviewed on Oct 13, 2026
Review provided by PeerSpot
What is our primary use case?
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.
How has it helped my organization?
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.
What is most valuable?
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.
What needs improvement?
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.
For how long have I used the solution?
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.
What do I think about the stability of the solution?
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.
What was our ROI?
The resource efficiency of VictoriaMetrics allows you to reduce infrastructure costs.
What other advice do I have?
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.
reviewer2910591
High availability metrics have enabled long-term monitoring across infrastructure and Kubernetes
Reviewed on Oct 13, 2026
Review provided by PeerSpot
What is our primary use case?
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.
What is most valuable?
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.
What needs improvement?
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.
For how long have I used the solution?
I have been using VictoriaMetrics for four years.
What do I think about the stability of the solution?
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.
What do I think about the scalability of the solution?
My experience with VictoriaMetrics's scalability is that it is perfect.
How are customer service and support?
I do not use customer support, but I know that it is good.
Which solution did I use previously and why did I switch?
Before VictoriaMetrics, I used Prometheus.
I decided to switch from Prometheus to VictoriaMetrics due to high availability and performance.
What was our ROI?
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.
What's my experience with pricing, setup cost, and licensing?
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.
Which other solutions did I evaluate?
Before choosing VictoriaMetrics, I did not evaluate other options.
What other advice do I have?
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.
Lmaina Mix
Embedded monitoring has improved cost efficiency and now supports unified metrics and traces
Reviewed on Oct 08, 2026
Review provided by PeerSpot
What is our primary use case?
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.
How has it helped my organization?
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.
What is most valuable?
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.
What needs improvement?
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.
For how long have I used the solution?
We have been using VictoriaMetrics since April 2026, which is about six months, and it has been great.
What do I think about the scalability of the solution?
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.
Which solution did I use previously and why did I switch?
Before using VictoriaMetrics, we previously utilized solutions such as Prometheus and Grafana, Elastic, and DataDog.
How was the initial setup?
VictoriaMetrics is deployed in our organization in a public cloud and it is very easy.
What was our ROI?
We have seen a return on investment with at least 30% of estimated cost saved with VictoriaMetrics.
What's my experience with pricing, setup cost, and licensing?
Regarding pricing, setup cost, and licensing, we are using open source today.
Which other solutions did I evaluate?
Before choosing VictoriaMetrics, we evaluated options such as Prometheus alone, Thanos, and Mimir.
What other advice do I have?
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.
reviewer2908245
Fast time series monitoring has enabled me to build rich dashboards and reports quickly
Reviewed on Oct 07, 2026
Review provided by PeerSpot
What is our primary use case?
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.
How has it helped my organization?
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.
What is most valuable?
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.
What needs improvement?
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.
For how long have I used the solution?
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.
What do I think about the stability of the solution?
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.
What do I think about the scalability of the solution?
I have no experience with upgrading VictoriaMetrics and I have had no need for upgrades. At this time, I cannot go into detail.
How are customer service and support?
I have not had the opportunity to interact with the support service of VictoriaMetrics.
Which solution did I use previously and why did I switch?
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.
How was the initial setup?
I have implemented VictoriaMetrics in my organization using on-premises infrastructure.
What was our ROI?
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.
What's my experience with pricing, setup cost, and licensing?
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.
Which other solutions did I evaluate?
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.
What other advice do I have?
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.