VictoriaLogs vs Loki - Benchmarkresultaten

TL;DR – Na een directe vergelijking op een workload van 500 GB/7 dagen verminderde VictoriaLogs de query-latentie met 94 %, krimpte de opslag met ≈40 % en verbruikte het < 50 % van de CPU & RAM die we eerder aan Loki toewezen. Dit artikel legt uit waarom we zijn overgestapt.

Achtergrond & Vereisten

Truefoundry helpt ontwikkelaars bij het draaien van multi-tenant ML-workloads op Kubernetes.
Ontwikkelaars hebben behoefte aan:

• Snelle, ad-hoc zoekopdrachten
• Goede Ingestion-snelheid
• Live tailing voor debugging.
• Minimale operationele overhead – voorkeur voor single-binary deployments.
• Resource-efficiënte werking op een node met 4 vCPU / 16 GiB RAM
• Hoge compressieverhouding op opgeslagen Logs
• Block Storage  > S3 verkozen, om overhead en latentie te verminderen.

Loki voldeed aanvankelijk goed, maar naarmate het volume groeide, zagen we query-latenties van >30 s en een hoge I/O-amplificatie. Dit was de aanleiding voor een evaluatie van VictoriaLogs.

Gartner Hype Cycle for Platform Engineering 2026

Toegang tot het volledige rapport van 2026

Wat is Loki?

Loki is het logaggregatiesysteem van Grafana Labs dat logs opslaat in gecomprimeerde chunks, vergezeld van een index gebouwd op basis van labels (sleutel-waardeparen). Queries worden uitgedrukt in LogQL en leunen zwaar op labelfilters gevolgd door regelfiltering.

• Sterke punten: nauwe Grafana-integratie, goedkope index, horizontaal schaalbaar.
• Beperkingen voor ons: index op basis van alleen labels betekent kostbare full-scan regex-zoekopdrachten; hoge chunk-compaction-I/O; Go GC-overhead bij hoge ingestion.

Wat is VictoriaLogs?

VictoriaLogs is een logdatabase ontwikkeld door het VictoriaMetrics-team. Het maakt gebruik van kolomgeoriënteerde LSM-achtige opslag met indices per veld, SIMD-geaccelereerd zoeken en een SQL-achtige LogSQL-syntaxis.

• Sterke punten: full-text index op alle tokens; single-binary; zeer lage geheugenfootprint; snelle scans op koude caches.
• Afwegingen: kleiner ecosysteem, minder ingebouwde integraties (we sturen data door via Vector).

Benchmarkmethodologie

Querysuite

1. Stats – totaal aantal regels voor een filter in de afgelopen 24 uur.
2. Needle in a Haystack – 3-4 statische regel-[UNIQUE-STATIC-LOG] ID=abc123 XYZ in een namespace met veel logs over 7 dagen.
3. Negative – string die niet bestaat (forceert een volledige scan) over 7 dagen.

🔍 Queryprestaties

1. Stats Query (aantal logs over 24u)

Doel: Totaal aantal logregels uit app="servicefoundry-server"

2. Needle-in-Haystack Query (7 dagen, ~500 GB)

Doel: Zoeken naar een unieke statische logregel in de truefoundry namespace

3. App Herstart Log Match (7 dagen) (Extra query om stap 2 te verifiëren)

Doel: Zoeken naar een bekend herstartpatroon :3000 in een kleine subset van logs (gericht op een enkele shard)
Er is geverifieerd dat de resultaatsets identiek waren.

4. Niet-bestaande Log Match (7 dagen)

Doel: Zoeken naar een niet-bestaande logregel, wat een zoekopdracht door alle data triggert
Er is geverifieerd dat de resultaatsets identiek waren.

Bij het verwerken van 500GB aan data vertoonde Loki vreemd gedrag. De resources raakten overbelast en de queryrespons bleef steken.

Loki vs VictoriaLogs: Resultaten in één oogopslag

Onze evaluatie richtte zich op drie dimensies die dagelijks van belang zijn voor platform engineers:

1. Hoe snel kunnen we antwoorden krijgen?
2. Hoeveel resources kost die snelheid?
3. Hoe stabiel is de ervaring onder daadwerkelijke belasting?

Queryprestaties

‍

Waarom dit verschil? VictoriaLogs onderhoudt een index per token, waardoor zelfs regex-achtige scans worden ondersteund door de index. Loki daarentegen filtert regel voor regel na een labelquery, wat uitmondt in een brute-force scan wanneer de labelset breed is.

🌪️ · Ingestion-prestaties

We hebben de ingestion ook aan een stresstest onderworpen met 120 replica's van onze  flog-generator.
De resultaten waren opmerkelijk:

Loki:

Loki piekt naar 3–4 vCPU, nadert de limiet van 8 GiB en vertoont throttling onder dezelfde workload

VictoriaLogs:

👉 Belangrijkste conclusie: VictoriaLogs leverde een 3× hogere ingestionsnelheid terwijl het 72% minder CPU en 87% minder geheugen verbruikte vergeleken met Loki.

VictoriaLogs blijft ruim onder de limieten van 4 vCPU / 8 GiB, zelfs tijdens ingestionpieken

2 · Resourcegebruik (retentie van 7 dagen)

Loki

Gebruikt geheugen:  consistent 6-7GB RAM
CPU-piek: 3 vCPU

‍

VictoriaLogs

Gebruikt geheugen: 800 MB - 900 MB
Piek CPU-gebruik: 1.1  vCPU

3 · Real-world belasting (Locust run van 2 min @ 10 gebruikers & 2 Rampup)

De queries waren vergelijkbaar, met willekeurige limieten en een willekeurig tijdsbereik, om cachepieken te garanderen.

VictoriaLogs

Loki

📌 Ondanks het verwerken van een 36% hogere RPS, liet VictoriaLogs lagere p95%- en tail-latenties zien — wat bewijst dat het indexeringsmodel standhoudt onder druk met een 3.6x snellere p99%ile

‍Deze test bevestigde onze beslissing: VictoriaLogs is niet alleen sneller in theorie — het schaalt beter onder druk in productie-achtige workloads.

Samenvatting van de cijfers

• 70–94 % sneller bij veelvoorkomende zoekpatronen.
• ≈40 % kleiner op schijf bij hetzelfde retentievenster.
• De helft van de rekenkracht, wat een volledige vCPU en ~1–2 GiB RAM vrijmaakt op onze kleinste nodes.

Kortom: Voor een log-intensieve, zoekgeoriënteerde toepassing stelt VictoriaLogs ons in staat om vragen in seconden in plaats van minuten te beantwoorden, terwijl de infrastructuurkosten dalen.

Belangrijkste bevindingen

1. Full-text index is essentieel – de per-token index van VictoriaLogs maakt brute-force regelfiltering overbodig.
2. Opslagstructuur – kolomgeoriënteerd + LSM vermindert de grootte op schijf en schijf-seeks aanzienlijk.
3. Geheugenefficiëntie – we maakten ~2 GiB RAM per node vrij, wat een dichtere scheduling mogelijk maakt.
4. Operationele eenvoud – beide zijn single-binary, maar VictoriaLogs had geen enkele aangepaste afstemming nodig om deze cijfers te behalen.

Conclusie

Voor workloadprofielen met veel ad-hoc tekstzoekopdrachten leverde VictoriaLogs orde van grootte snellere queries op en aanzienlijke kostenbesparingen. Loki blijft een uitstekende keuze wanneer een nauwe Grafana-integratie en label-first queries overheersen, maar VictoriaLogs is nu onze standaard voor clusters met hoge ingestion en een sterke focus op ontwikkelaars.

Referenties

• Loki-documentatie
• VictoriaLogs-documentatie
• Promtail-documentatie
• Vector-documentatie
• Alloy-documentatie
• Grafana Alloy Configurator

Veelgestelde vragen

Wat is het belangrijkste verschil tussen VictoriaLogs en Loki?

Het belangrijkste verschil in VictoriaLogs vs Loki is de geavanceerde per-token indexering en kolomgeoriënteerde opslag van VictoriaLogs. Dit maakt veel snellere queryprestaties en een aanzienlijk lager resourcegebruik mogelijk vergeleken met Loki's indexering op basis van alleen labels, wat vaak leidt tot tragere full-scan zoekopdrachten en een hogere operationele overhead voor logbeheer.

Is VictoriaLogs sneller dan Loki?

Ja, in onze grondige benchmarking vertoonde VictoriaLogs superieure snelheid vergeleken met Loki. Bij vergelijkingen van VictoriaLogs vs Loki verminderde VictoriaLogs de query-latentie met 94% en behaalde het 12x snellere zoektijden voor complexe queries. Het leverde ook een 3x hogere ingestion-prestatie, wat het aanzienlijk efficiënter maakt.

Wat is de standaardpoort voor VictoriaLogs?

Bij het evalueren van VictoriaLogs vs Loki is kennis van de installatiedetails nuttig. VictoriaLogs gebruikt doorgaans poort 8428 voor de standaard HTTP API- en scraping-endpoints. Deze poort biedt toegang tot en interactie met de logdatabase. Hoewel onze blog zich richt op prestaties, is het begrijpen van de basisprincipes van deployment, zoals de standaardpoort, cruciaal voor de systeemconfiguratie.

Wat zijn de benchmarkresultaten van VictoriaLogs vs Loki?

In benchmarks waarin VictoriaLogs vs Loki worden vergeleken, leverde VictoriaLogs superieure prestaties. Het behaalde een reductie van 94% in query-latenties, verminderde het opslaggebruik met ongeveer 40% en verbruikte minder dan 50% van de toegewezen CPU en RAM. VictoriaLogs vertoonde ook een 3x hogere ingestion-doorvoer, wat het uitermate efficiënt maakt.

Welke is beter: VictoriaLogs of Loki?

In onze benchmark van VictoriaLogs vs Loki bleek VictoriaLogs superieur. Het verkortte query-latenties met 94%, verminderde opslag met 40% en gebruikte ruim 50% minder CPU/RAM. TrueFoundry heeft gekozen voor VictoriaLogs vanwege de verbeterde prestaties en efficiëntie bij het beheren van ML-workloads.