Loki is Grafana‑Labs’ log aggregation system that stores logs in compressed chunks accompanied by an index built from labels (key–value pairs). Queries are expressed in LogQL and rely heavily on label filters followed by line filtering.

What Is VictoriaLogs?

VictoriaLogs is a log database by the VictoriaMetrics team. It uses columnar LSM‑style storage with per‑field indices, SIMD‑accelerated search and SQL‑like LogSQL syntax.

What is the key difference betweeen Victorialogs and Loki?

The key difference in victorialogs vs loki is VictoriaLogs' advanced per-token indexing and columnar storage. This enables much faster query performance and significantly lower resource usage compared to Loki's label-only indexing, which often results in slower full-scan searches and higher operational overhead for log management.

Is VictoriaLogs faster than Loki?

Yes, in our rigorous benchmarking, VictoriaLogs demonstrated superior speed compared to Loki. For victorialogs vs loki comparisons, VictoriaLogs reduced query latencies by 94% and achieved 12x faster search times for complex queries. It also delivered 3x higher ingestion performance, making it significantly more efficient.

What is the default port for VictoriaLogs?

When evaluating victorialogs vs loki, knowing setup details is helpful. VictoriaLogs typically uses port 8428 for its default HTTP API and scraping endpoints. This port allows access and interaction with the log database. While our blog focuses on performance, understanding deployment basics, like the default port, is crucial for system configuration.

What are VictoriaLogs vs Loki benchmark results?

In benchmarks comparing victorialogs vs loki, VictoriaLogs delivered superior performance. It achieved a 94% reduction in query latencies, decreased storage usage by approximately 40%, and consumed less than 50% of allocated CPU and RAM. VictoriaLogs also showcased 3x higher ingestion throughput, making it highly efficient.

Which is better: VictoriaLogs or Loki?

In our benchmark of victorialogs vs loki, VictoriaLogs proved superior. It cut query latencies by 94%, reduced storage by 40%, and used over 50% less CPU/RAM. TrueFoundry in the US chose VictoriaLogs for its enhanced performance and efficiency managing ML workloads.

VictoriaLogs vs Loki - Resultados do Benchmark

By Harshit Luthra

Updated: July 9, 2025

Built for Speed: ~10ms Latency, Even Under Load

Blazingly fast way to build, track and deploy your models!

Handles 350+ RPS on just 1 vCPU — no tuning needed
Production-ready with full enterprise support

Get Started with Truefoundry Now Talk to the Expert

TL;DR – Após testes lado a lado em uma carga de trabalho de 500 GB/7 dias, o VictoriaLogs reduziu as latências de consulta em 94 %, diminuiu o armazenamento em ≈40 %, e usou < 50 % da CPU e RAM que alocávamos anteriormente ao Loki. Esta publicação explica por que trocamos.

Contexto e Requisitos

A Truefoundry ajuda os desenvolvedores a executar cargas de trabalho de ML multi-tenant no Kubernetes.
Os desenvolvedores precisam:

Pesquisa rápida e ad hoc
Boa ingestão de dados
Acompanhamento em tempo real para depuração.
Sobrecarga operacional mínima – preferencialmente implantações de binário único.
Eficiente em recursos operação em um 4 vCPU / 16 GiB RAM nó
Alta compressão taxa em Logs armazenados
Armazenamento em Bloco > S3 preferencial, para reduzir a sobrecarga. + Latência

O Loki nos atendeu bem inicialmente, mas à medida que o volume cresceu, observamos latências de busca superiores a 30 segundos e alta amplificação de E/S. Isso desencadeou uma avaliação do VictoriaLogs.

How Can You Prevent GenAI Costs From Spiraling at Scale?

Access Full 2026 Report

O Que É Loki?

Loki é o sistema de agregação de logs da Grafana-Labs que armazena logs em blocos compactados, acompanhados por um índice construído a partir de rótulos (pares chave-valor). As consultas são expressas em LogQL e dependem fortemente de filtros de rótulo seguidos por filtragem de linha.

Pontos Fortes: integração robusta com Grafana, índice econômico, escalável horizontalmente.
Limitações para nós: índice apenas de rótulos significa buscas regex de varredura completa caras; alta E/S de compactação de blocos; sobrecarga do GC do Go em alta ingestão.

O que é VictoriaLogs?

VictoriaLogs é um banco de dados de logs da equipe VictoriaMetrics. Ele usa armazenamento colunar estilo LSM com índices por campo, busca acelerada por SIMD e LogSQL semelhante a SQL sintaxe.

Pontos fortes: índice de texto completo em todos os tokens; binário único; consumo de memória muito baixo; varreduras rápidas de cache frio.
Compromissos: ecossistema menor, menos integrações nativas (nós enviamos dados via Vector).

Metodologia de Benchmark

Category	Details
Requests/Memory	(4 vCPU, 8 GiB RAM) – identical for both systems, QoS: Guaranteed
Log Generator	flog pushing 65 MB/s to Vector → Loki / Vector → VictoriaLogs
Data Set	~500 GB over 7 days; mixed duplicate & unique lines; 20 namespaces, 40 apps
Retention	7 days
Clients	Locust 2.27.1, 10 virtual users, sustained 43 RPS to /select/logsql/query Grafana
Queries Tested	Stats, Needle in a Haystack, Regex, Negative (details below)
Caching	Block-cache disabled for both systems to simulate cold reads; pods were restarted to ensure this.
Index Tweaks	Loki: defaults; VictoriaLogs: defaults

Conjunto de Consultas

Estatísticas – total de linhas para um filtro nas últimas 24 horas.
Agulha no Palheiro – 3-4 linha estática [UNIQUE-STATIC-LOG] ID=abc123 XYZ em namespace com muitos logs ao longo de 7 dias.
Negativo – string que não existe (força varredura completa) ao longo de 7 dias.

🔍 Desempenho da Consulta

1. Consulta de Estatísticas (contagem de logs nas últimas 24h)

Propósito: Total de linhas de log de app="servicefoundry-server"

System	Query	Latency
Loki	sum(count_over_time({app="servicefoundry-server"}[24h]))	2.5s
VictoriaLogs	{app="servicefoundry-server"} \| stats count()	1.5s

2. Consulta Agulha no Palheiro (7 dias, ~500 GB)

Propósito: Procurar por uma linha de log estática única no truefoundry namespace

System	Query	Latency
Loki	{namespace="truefoundry", app!="grafana"} \|= "[UNIQUE-STATIC-LOG] ID=abc123 XYZ"	12s
VictoriaLogs	{namespace="truefoundry", app!="grafana"} "[UNIQUE-STATIC-LOG] ID=abc123 XYZ"	~900ms

3. Correspondência de Log de Reinício de Aplicativo (7 dias) (Consulta extra para verificar o Passo 2)

Propósito: Procurar por padrão de reinício conhecido :3000 em um pequeno subconjunto de logs (visando um único shard)
Os conjuntos de resultados foram verificados como idênticos.

System	Query	Latency
Loki	{app="servicefoundry-server"} \|= ":3000"	~2.2 s
VictoriaLogs	{app="servicefoundry-server"} ":3000"	~2.2 s

4. Correspondência de Log de Não Existência (7 dias)

Objetivo: Procurar por log não existente, acionando uma busca completa de dados
Os conjuntos de resultados foram verificados como idênticos.

Ao processar 500GB de dados, Loki se comportou de forma estranha. Os recursos ficaram sobrecarregados e a resposta da consulta parou.

System	Query	Latency
Loki (500 GB)	{namespace="truefoundry"} \|= "non-existent log line"	Timeout
VictoriaLogs (500 GB)	{namespace="truefoundry"} "non-existent log line"	2.2s
Loki (300 GB)	{namespace="truefoundry"} \|= "non-existent log line"	2.6s
VictoriaLogs (300 GB)	{namespace="truefoundry"} "non-existent log line"	266ms

Loki vs VictoriaLogs: Resultados em Destaque

Nossa avaliação focou em três dimensões que são importantes no dia a dia para engenheiros de plataforma:

Com que rapidez podemos obter respostas?
Quantos recursos essa velocidade custa?
Quão estável é a experiência sob carga real?

Desempenho da Consulta

Workload	Loki	VictoriaLogs	Speed-up
Stats (24h)	2.5s	1.5s	40 % faster
Needle (500 GB)	12s	1s	12× faster
Pattern “:3000” (7d)	2.2s	2.2s	same result
Negative (7d)	2.6s	266ms	10× faster

‍

Por que a diferença? VictoriaLogs mantém um índice por token, então até mesmo varreduras tipo regex são assistidas por índice. Loki, por outro lado, filtra linha por linha após uma consulta de rótulo, o que se transforma em uma varredura de força bruta quando o conjunto de rótulos é amplo.

🌪️ · Desempenho de Ingestão

Também realizamos testes de estresse na ingestão com 120 réplicas do nosso flog gerador.
Os resultados foram reveladores:

Metric	Loki	VictoriaLogs	Outcome
Peak Ingestion	20 MB/s	66 MB/s	3× higher throughput
vCPU Usage	4 vCPUs (100 % throttled)	2 vCPUs peak	≥50 % reduction
Memory Usage	≈4 GiB	≈1.3 GiB	~3× lower

Loki:

Loki atinge picos de 3–4 vCPU, aproxima-se do seu limite de 8 GiB e apresenta estrangulamento sob a mesma carga de trabalho

VictoriaLogs:

👉 Principal conclusão: VictoriaLogs proporcionou 3 vezes maior velocidade de ingestão consumindo 72% menos CPU e 87% menos memória comparado ao Loki.

VictoriaLogs mantém-se confortavelmente abaixo dos seus limites de 4 vCPU / 8 GiB mesmo durante picos de ingestão

2 · Consumo de Recursos (retenção de 7 dias)

Loki

Memória Utilizada: utilizando consistentemente 6-7GB RAM
Pico de CPU: 3 vCPU

‍

VictoriaLogs

Memória Utilizada: 800 MB - 900 MB
Pico de Uso da CPU: 1.1 vCPU

	Loki	VictoriaLogs	Delta
Storage	501 GiB	318 GiB	37 %
Memory	6–7 GiB steady	0.6–2 GiB	33–80 %
CPU peak	4 vCPU (throttled)	1.1 vCPU	73 %

3 · Carga do Mundo Real (Execução de 2 minutos do Locust @ 10 usuários e 2 Rampup)

As consultas foram semelhantes, com Limites Aleatórios e Intervalos de Tempo Aleatórios, para garantir picos de Cache.

Victoria Logs

Loki

📌 Apesar de lidar com 36% mais RPS, o VictoriaLogs apresentou latências p95% e de cauda mais baixas — provando que seu modelo de indexação se mantém sob pressão com 3.6x mais rápido p99%il

‍Este teste reforçou nossa decisão: o VictoriaLogs não é apenas mais rápido na teoria — ele escala melhor sob estresse em cargas de trabalho semelhantes às de produção.

Resumo dos Números

70–94 % mais rápido em padrões de busca comuns.
≈40 % menor em disco com a mesma janela de retenção.
Metade do poder de processamento, liberando uma vCPU completa e ~1–2 GiB de RAM nos nossos nós menores.

Em resumo: Para um cenário de uso intensivo de logs e centrado em pesquisa, o VictoriaLogs permite-nos responder a perguntas em segundos em vez de minutos, ao mesmo tempo que reduz os custos de infraestrutura.

Principais Descobertas

O índice de texto completo é importante – o índice por token do VictoriaLogs elimina a filtragem de linhas por força bruta.
Layout de armazenamento – columnar + LSM reduz drasticamente o tamanho em disco e as buscas em disco.
Eficiência de memória – liberamos ~2 GiB de RAM por nó, permitindo um agendamento mais denso.
Simplicidade operacional – ambos são de binário único, mas o VictoriaLogs precisou de zero ajustes personalizados para atingir estes números.

Conclusão

Para perfis de carga de trabalho que dependem muito de pesquisa de texto ad hoc, o VictoriaLogs proporcionou uma ordem de magnitude consultas mais rápidas e economias de custo significativas. O Loki continua a ser uma excelente escolha quando a integração apertada com o Grafana e as consultas baseadas em rótulos dominam, mas o VictoriaLogs é agora o nosso padrão para clusters de alta ingestão e centrados no desenvolvedor.

Referências

Perguntas Frequentes

Qual é a principal diferença entre VictoriaLogs e Loki?

A principal diferença entre VictoriaLogs e Loki reside na indexação avançada por token e no armazenamento colunar do VictoriaLogs. Isso permite um desempenho de consulta muito mais rápido e um uso de recursos significativamente menor em comparação com a indexação apenas por rótulos do Loki, que frequentemente resulta em pesquisas de varredura completa mais lentas e maior sobrecarga operacional para o gerenciamento de logs.

O VictoriaLogs é mais rápido que o Loki?

Sim, em nossos rigorosos testes de benchmark, o VictoriaLogs demonstrou velocidade superior em comparação com o Loki. Para comparações entre VictoriaLogs e Loki, o VictoriaLogs reduziu as latências de consulta em 94% e alcançou tempos de busca 12 vezes mais rápidos para consultas complexas. Ele também entregou um desempenho de ingestão 3 vezes maior, tornando-o significativamente mais eficiente.

Qual é a porta padrão para o VictoriaLogs?

Ao avaliar VictoriaLogs vs Loki, conhecer os detalhes de configuração é útil. O VictoriaLogs geralmente usa a porta 8428 para sua API HTTP padrão e endpoints de scraping. Esta porta permite o acesso e a interação com o banco de dados de logs. Embora nosso blog se concentre no desempenho, entender os fundamentos da implantação, como a porta padrão, é crucial para a configuração do sistema.

Quais são os resultados do benchmark VictoriaLogs vs Loki?

Em benchmarks comparando VictoriaLogs vs Loki, o VictoriaLogs entregou desempenho superior. Ele alcançou uma redução de 94% nas latências de consulta, diminuiu o uso de armazenamento em aproximadamente 40% e consumiu menos de 50% da CPU e RAM alocadas. O VictoriaLogs também demonstrou uma taxa de transferência de ingestão 3 vezes maior, tornando-o altamente eficiente.

Qual é melhor: VictoriaLogs ou Loki?

Em nosso benchmark de VictoriaLogs vs Loki, o VictoriaLogs provou ser superior. Ele reduziu as latências de consulta em 94%, o armazenamento em 40% e usou mais de 50% menos CPU/RAM. A TrueFoundry nos EUA escolheu o VictoriaLogs por seu desempenho e eficiência aprimorados no gerenciamento de cargas de trabalho de ML.

TrueFoundry AI Gateway delivers ~3–4 ms latency, handles 350+ RPS on 1 vCPU, scales horizontally with ease, and is production-ready, while LiteLLM suffers from high latency, struggles beyond moderate RPS, lacks built-in scaling, and is best for light or prototype workloads.

Built for Speed: ~10ms Latency, Even Under Load

Schedule your Demo Now