VictoriaMetrics vs Prometheus: Qual escolher em 2026?

O debate VictoriaMetrics vs Prometheus deixou de ser técnico curioso e virou decisão arquitetural concreta. Os times de SRE e plataforma cresceram. A cardinalidade explodiu. Em paralelo, a conta do storage chegou. Nesse cenário, escolher o banco de séries temporais errado custa caro em RAM, em horas de operação e em ciclos de incidente.

Prometheus continua sendo o padrão de fato em ambientes Kubernetes. Por outro lado, o VictoriaMetrics avança rápido como alternativa de longo prazo, com compressão agressiva e cluster nativo. Em suma, a pergunta deixou de ser “qual é melhor?” e passou a ser “qual encaixa no meu cenário?”.

Neste guia, comparamos os dois lado a lado em performance, armazenamento, linguagem de query, alta disponibilidade e custo operacional. Em seguida, apresentamos uma tabela de decisão por cenário e um caminho prático de migração. O objetivo é simples: dar para o seu time uma resposta direta sem precisar virar três fins de semana lendo benchmarks.

O que é VictoriaMetrics e o que é Prometheus

Prometheus é um sistema de monitoramento e banco de séries temporais open source, criado no SoundCloud em 2012. Em 2018, a CNCF o promoveu para projeto graduado ao lado de outros projetos de infraestrutura cloud-native. Em essência, ele coleta métricas via modelo pull, armazena localmente e expõe a linguagem de consulta PromQL. Por isso, virou referência em ambientes cloud-native e a base de quase toda stack moderna de observabilidade em ambientes distribuídos.

VictoriaMetrics é um banco de séries temporais open source criado em 2018, compatível com a API do Prometheus. Ele aceita ingestão por pull e por push, suporta cluster nativo e foca em três coisas: alta taxa de ingestão, baixo consumo de RAM e compressão agressiva no disco. Além disso, oferece sua própria linguagem MetricsQL, que estende PromQL com funções adicionais.

Nesse sentido, os dois projetos resolvem o mesmo problema central: armazenar e consultar métricas em escala. No entanto, partem de filosofias diferentes. Prometheus prioriza simplicidade e ecossistema; já o VictoriaMetrics prioriza eficiência operacional em alto volume.

Diferenças de arquitetura: pull vs push, single-node vs cluster

Prometheus opera no modelo pull. Ou seja, o servidor faz scrape periódico de endpoints HTTP expostos pelos alvos monitorados. A configuração mora num arquivo prometheus.yml com scrape_configs e regras de discovery. Em compensação, o desenho é single-node por padrão. Isso mantém o setup simples, mas limita o caminho de escala horizontal.

# Scrape de targets via modelo pull
scrape_configs:
  - job_name: "node-exporter"
    scrape_interval: 15s
    static_configs:
      - targets: ["10.0.0.10:9100", "10.0.0.11:9100"]

VictoriaMetrics, por sua vez, aceita pull e push de forma nativa. Você pode usar o vmagent para fazer scrape compatível com Prometheus, ou enviar dados via remote_write, OpenTelemetry, InfluxDB line protocol e outros formatos. A arquitetura de cluster vem pronta de fábrica, com três componentes principais: vminsert, vmselect e vmstorage.

Em ambientes que rodam workloads críticos em Kubernetes, essa diferença pesa. O cluster nativo do VictoriaMetrics distribui ingestão e queries entre nós. Já o Prometheus exige federation, sharding manual ou um companion como Thanos para chegar ao mesmo lugar.

Performance, memória e CPU: o que os benchmarks mostram

Os números públicos de benchmark consistentemente colocam o VictoriaMetrics à frente em consumo de recursos. Cargas idênticas mostram CPU médio cerca de sete vezes menor e uso de RAM (RSS) quatro a cinco vezes menor que Prometheus. Em testes com milhões de séries ativas, a diferença vira fator decisivo de capacity planning.

A taxa de ingestão também diverge. Prometheus sustenta na casa de centenas de milhares de samples por segundo em hardware comum. Já o VictoriaMetrics escala para milhões de samples por segundo com a mesma configuração. Vale destacar que esses números variam por cenário, por isso recomendamos sempre rodar seu próprio load test antes da decisão final.

A pior dor crônica do Prometheus aparece em alta cardinalidade. Conforme relatos públicos, ambientes Kubernetes com mais de cem mil séries únicas chegam a consumir 200 GB de RAM antes de cair em OOMKilled. Como resultado, a equipe gasta noites ajustando relabel rules para conter cardinalidade. Do mesmo modo, ambientes com tags dinâmicas (como pod_id) precisam de cuidado redobrado.

Compressão e armazenamento de longo prazo

Aqui mora o diferencial mais citado do VictoriaMetrics. O algoritmo de compressão proprietário entrega entre cinco e dez vezes mais economia de disco que o TSDB nativo do Prometheus para o mesmo conjunto de dados. Em números concretos, fala-se em 0,4–0,8 bytes por sample no VictoriaMetrics contra 5–10 bytes por sample no Prometheus.

Outro ponto importante: Prometheus não foi projetado para retenção longa. A documentação oficial recomenda 15 a 30 dias de retenção local. Para guardar anos de histórico, você precisa adicionar remote_write para um storage externo, normalmente Thanos, Cortex ou o próprio VictoriaMetrics. Em contrapartida, o VictoriaMetrics aguenta anos de retenção local sem componentes extras.

A diferença muda o desenho da operação. Ademais, ajustar downsampling e compactação no Prometheus exige integração com ferramentas externas; no VictoriaMetrics, essas funções vêm embutidas. Para times que medem custos por indicadores de TI e por TCO de longo prazo, o impacto financeiro acumulado é significativo.

PromQL vs MetricsQL: o que muda na prática

VictoriaMetrics implementa MetricsQL, que é compatível com PromQL e estende a linguagem com novas funções. Em outras palavras, queries do seu Prometheus rodam no VictoriaMetrics sem reescrita. Por outro lado, o caminho contrário não vale: queries que usam funções exclusivas do MetricsQL (como histogram_avg, rollup, WITH templates) não rodam no Prometheus.

# Taxa de erro HTTP por servico (funciona em ambos)
sum by (service) (
  rate(http_requests_total{status=~"5.."}[5m])
) / sum by (service) (
  rate(http_requests_total[5m])
)

Por fim, vale destacar dois pontos práticos. Primeiro, alertas escritos em PromQL migram diretos para o vmalert (componente de alerta do VictoriaMetrics). Segundo, dashboards do Grafana montados em cima de Prometheus continuam funcionando ao trocar o data source. Basta apontar para a URL do VictoriaMetrics e validar os painéis em produção. Para mais detalhes sobre regras de alerta e linguagem, vale consultar a documentação oficial do projeto upstream.

Alta disponibilidade e escala horizontal

Prometheus não tem alta disponibilidade nativa. O padrão recomendado é rodar duas instâncias idênticas em paralelo e usar Alertmanager para deduplicar alertas. Ainda assim, queries continuam consultando uma instância por vez. Isso cria pontos cegos durante reinício, manutenção e falhas de scrape em uma das réplicas.

VictoriaMetrics oferece replicação no nível do cluster. O vminsert escreve em N réplicas e o vmstorage guarda os dados em shards independentes. Já o vmselect consolida resultados de todos os shards na consulta. Como resultado, o cluster sobrevive a perdas parciais de nós sem precisar duplicar todo o storage.

Para escala horizontal pura, ou seja, crescer a capacidade de ingestão e query adicionando nós, o VictoriaMetrics resolve de forma nativa. Já o Prometheus exige soluções complementares como Thanos, Cortex ou Grafana Mimir para chegar ao mesmo modelo distribuído. Cada uma adiciona componentes extras, complexidade operacional e mais um deploy para o time cuidar.

Comparativo lado a lado

A tabela abaixo resume as dimensões mais consultadas por times que avaliam VictoriaMetrics vs Prometheus:

Integração com Grafana, Kubernetes e OpenTelemetry

Em ambos os casos, o Grafana é o frontend padrão. Adicione o data source como Prometheus (vale para os dois) e seus dashboards funcionam imediatamente. Por isso, a maioria das equipes que avalia migração tem zero esforço de retrabalho nos painéis existentes.

Em Kubernetes, o cenário tem dois caminhos consolidados. O Prometheus aparece via kube-prometheus-stack (Operator + Helm chart), com regras prontas para nodes, pods e control plane. Já o VictoriaMetrics oferece o VictoriaMetrics Operator e o helm chart vm-stack, com integração direta para CRDs PrometheusRule e ServiceMonitor. Ou seja, configurações existentes migram sem reescrita.

Quanto à telemetria moderna baseada em OpenTelemetry, ambos aceitam métricas via remote_write. Adicionalmente, o VictoriaMetrics aceita ingestão nativa via OTLP HTTP, eliminando a necessidade de exporters intermediários. Para times que padronizaram em OpenTelemetry como instrumentação única, isso simplifica o pipeline de ponta a ponta.

Quando escolher cada um: tabela de decisão

Não existe vencedor absoluto. A escolha depende de cardinalidade, retenção, time disponível e orçamento. A tabela abaixo mapeia cenários típicos contra a recomendação mais frequente em deployments de observabilidade em produção:

O padrão híbrido também ganhou popularidade. Em outras palavras, muitos times mantêm Prometheus para scrape e regras (onde ele é imbatível). Em paralelo, usam VictoriaMetrics como long-term storage via remote_write. Esse arranjo combina a maturidade operacional do Prometheus com a eficiência de storage do VictoriaMetrics.

Como migrar do Prometheus para o VictoriaMetrics

A migração tem baixo atrito porque o VictoriaMetrics aceita a API do Prometheus de ponta a ponta. Em três passos práticos: subir o VictoriaMetrics em paralelo, redirecionar a escrita, validar e desligar o storage antigo. Veja o caminho mais comum:

# Replicar amostras para o VictoriaMetrics
remote_write:
  - url: "http://vminsert:8480/insert/0/prometheus/api/v1/write"
    queue_config:
      max_samples_per_send: 10000
      capacity: 25000

Em seguida, use o vmctl para importar o histórico do Prometheus em background. A ferramenta lê snapshots do TSDB local e escreve no VictoriaMetrics em paralelo. Posteriormente, troque o data source do Grafana para apontar para o vmselect. Em seguida, valide os dashboards mais críticos antes de desligar a escrita no Prometheus.

Para quem já tem Prometheus em produção, o caminho mais seguro é rodar em paralelo por duas a quatro semanas. Dessa forma, você ganha confiança nos números, valida alertas e ajusta capacidade do cluster. Vale dizer que a maior parte dos problemas aparece em consultas de longo range, então priorize dashboards de SLO e capacity nessa validação.

Conclusão

Na disputa VictoriaMetrics vs Prometheus, a resposta certa depende do estágio em que a sua operação está. Em ambientes pequenos a médios, com retenção curta e cardinalidade controlada, o Prometheus continua sendo a escolha mais simples, segura e barata. Por outro lado, o VictoriaMetrics entrega um caminho mais limpo quando a cardinalidade dispara, a retenção precisa de mais meses ou o time já gasta horas com OOMs.

Em muitos casos, a melhor decisão não é “trocar tudo”, mas combinar. Use Prometheus para scrape e regras. Em paralelo, deixe o VictoriaMetrics como long-term storage e camada de queries de longo range. Em última análise, a escolha técnica precisa nascer do contexto da operação, não da torcida por uma marca. Para discutir o desenho ideal para o seu ambiente, fale com nossos especialistas em observabilidade e monitoramento.