VictoriaLogs

Last reviewed Sep 13, 2026 · 932 words

VictoriaLogs stores and searches logs on hardware that Loki finds cramped and Elasticsearch finds insulting. The floor is 256 MB of RAM, the whole thing is one Go binary listening on port 9428, and it needs no labels design, no schema, and no companion services to be useful. It is also the newest tool in its class, first released in 2023 and sitting at 2,268 stars, which is the trade you make: the best resource profile in self-hosted logging, with a shorter track record than the incumbents.

One binary, one port, one flag that matters

The install is a single container with a data volume. Of the dozens of flags, -retentionPeriod is the one to set consciously, because the default is long enough that a busy host fills a disk before you think about it.

services:
  victorialogs:
    image: victoriametrics/victoria-logs:latest
    command:
      - -storageDataPath=/vlogs
      - -retentionPeriod=30d
    volumes:
      - ./vlogs-data:/vlogs
    ports:
      - "9428:9428"
    restart: unless-stopped

Once it is up, http://host:9428/select/vmui gives you a built-in query UI, so you can search before you install anything else. Storage is columnar and compressed hard; the project's own numbers claim an order of magnitude less disk than Elasticsearch for the same lines, and while I treat vendor benchmarks as vendor benchmarks, the direction matches what I see. Memory use scales with query concurrency far more than with ingest rate, so a homelab instance that only you query stays near the floor.

Getting Docker logs into it

The reason this is easy is that VictoriaLogs speaks other people's ingestion protocols. It accepts the Loki push API, the Elasticsearch bulk API, JSON lines, syslog, and OpenTelemetry, so whatever shipper you already have keeps working with a URL change. For a Docker host the two shippers worth considering are Vector and Fluent Bit; both tail the Docker socket, both add the container name and image as fields, and both can push to http://victorialogs:9428/insert/loki/api/v1/push or the native JSON endpoint. The Docker Loki logging driver works too, because from its point of view the target is a Loki. On Kubernetes the same applies to whatever DaemonSet you already run.

The one decision to make at ingest time is which fields become the stream identity. VictoriaLogs groups lines by stream fields (typically container or pod plus namespace) for fast filtering, and everything else is stored as ordinary fields you can still search on. Unlike Loki, getting this wrong is not fatal, because nothing about the storage engine punishes you for high cardinality in non-stream fields.

LogsQL is grep with a time axis

Queries read like a search box, not a query language, which is deliberate. A time window, a word, and an exclusion:

_time:1h error -healthcheck

Restrict to one stream with _stream:{container="caddy"}, filter a field with status:500, and chain pipes for aggregation: | stats by (container) count() gives you an error count per service. Phrase search, prefix search, and regex are all there, and full-text search across every field is the default rather than something you enable per index. This is the practical difference from Loki, where LogQL makes you name a label set before it will search anything, and from Elasticsearch, where you tune analyzers. For a self-hoster whose logging need is "what happened at 03:14 and which container did it", LogsQL answers in one line.

Versus Loki, and the Grafana question

Loki is the safe pick when you already run the Grafana stack and want the option that Grafana Labs supports first. It is also the one that punishes careless labels with runaway index size, and it wants object storage plus a couple of components for anything past a toy setup. VictoriaLogs has an official Grafana datasource plugin, so dashboards and the Explore view work the same way; you install the plugin from the Grafana catalogue and point it at port 9428. If you also run VictoriaMetrics for metrics, the two share conventions, alerting through vmalert, and a team, which is the strongest argument for the pairing. Graylog is the other direction entirely: heavier, Java, Elasticsearch or OpenSearch underneath, but with a mature alerting and role model that VictoriaLogs does not attempt.

The honest caveats: age and ecosystem

Two things are true at once. The project has moved fast, shipping features that were missing at launch (alerting via vmalert, a cluster mode, the Grafana plugin, syslog and OpenTelemetry ingestion), and it has not had a data-loss incident that I know of. It is also three years old with a smaller community than Loki, fewer third-party dashboards, and fewer forum answers when something odd happens. If your logs are compliance evidence, the shorter track record is a real cost. If they are the thing you grep when a container misbehaves, it is not. The monitoring category covers the metrics side that should sit beside any of these.

What I'd do

Run VictoriaLogs with a 30-day retention, ship with Vector using the container name as the stream field, and install the Grafana plugin on day one so you never open two UIs. On a homelab I would pick it over Loki without hesitation: the memory difference alone pays for itself on a mini PC, and LogsQL is what I want log search to feel like. In a team setting with an existing Loki and a Grafana Cloud subscription, stay on Loki; the operational gain does not outweigh re-learning a stack that already works.