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.
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 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.
My main use case is storing and querying the time-series metrics for monitoring and observability. I primarily use it as a high-performance back end for Prometheus, where it handles large volumes of metrics data efficiently. In my day-to-day workflow, application and infrastructure metrics are scraped via Prometheus and stored in VictoriaMetrics. I then use it with visualization tools like Grafana to monitor system health, track performance, and troubleshoot issues. This setup helps me handle high data ingestion with lower resource usage. One more thing I would add is how it helps with scalability and long-term data retention. I use it to store metrics over long periods without a significant increase in storage cost, which is very useful for trend analysis and capacity planning. It allows me to look back at historical data and make better decisions about scaling and performance optimization. Also, its ability to handle high ingestion rates with consistent performance makes it reliable for production environments, especially when monitoring multiple services and infrastructure components at scale.
Teams that switch to VictoriaMetrics report 70% less RAM and 75% less disk (verified PeerSpot user reviews), and cloud bills up to 10x lower (Grammarly case study) — while keeping their existing dashboards and alerting rules working. It is an open source observability solution for metrics, logs, and traces: a drop-in replacement for Prometheus and other backends that keeps scaling when data volume, query speed, or cost no longer does. It runs anywhere — from a Raspberry Pi to thousand-core...
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.
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 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.
My main use case is storing and querying the time-series metrics for monitoring and observability. I primarily use it as a high-performance back end for Prometheus, where it handles large volumes of metrics data efficiently. In my day-to-day workflow, application and infrastructure metrics are scraped via Prometheus and stored in VictoriaMetrics. I then use it with visualization tools like Grafana to monitor system health, track performance, and troubleshoot issues. This setup helps me handle high data ingestion with lower resource usage. One more thing I would add is how it helps with scalability and long-term data retention. I use it to store metrics over long periods without a significant increase in storage cost, which is very useful for trend analysis and capacity planning. It allows me to look back at historical data and make better decisions about scaling and performance optimization. Also, its ability to handle high ingestion rates with consistent performance makes it reliable for production environments, especially when monitoring multiple services and infrastructure components at scale.