Log storage in 2026: revisit Grafana Loki, VictoriaLogs and OpenObserve before you keep another month of logs

Manoj Shukla
October 15, 2026

Picture a platform team in Pune that runs a B2B lending stack for NBFCs across Maharashtra and Gujarat (an invented example, not a real client). About sixty microservices on Kubernetes write JSON logs through Fluent Bit and the OpenTelemetry Collector. Finance wants ninety days of searchable history for dispute tickets. Security wants thirty days hot for incident response. The object-storage bill for “keep everything forever” is climbing every month. One engineer wants Grafana Loki, because “we already run Grafana and Prometheus labels”. Another wants VictoriaLogs, because “one binary, full-text, high cardinality is fine”. A third wants a columnar store and names ClickHouse, then wonders whether to assemble ClickStack (ClickHouse plus HyperDX) or pick OpenObserve, which already ships Parquet on object storage with SQL. Legal asks about AGPL versus Apache 2.0 before the purchase order for another year of S3 capacity.

This post compares three self-hosted log storage backends as they stand on 15 October 2026. It is about where log lines live after your pipeline ships them, not about how you collect them. For collectors and processors, see the earlier post on Fluent Bit, Vector and the OpenTelemetry Collector. For Elasticsearch and OpenSearch as a search fork, see that comparison separately. For metrics long-term storage and for spans, see the Thanos/Mimir/VictoriaMetrics and Jaeger/Tempo/SigNoz posts. For ClickHouse as an OLAP warehouse, see the real-time OLAP post; that angle is related but not the same as picking a log product.

Why OpenObserve as the third option, not ClickStack or raw ClickHouse. ClickStack is an observability stack: ClickHouse for events, HyperDX for UI, an OpenTelemetry collector, and MongoDB for application state. That is a valid path if you already operate ClickHouse and want HyperDX’s search UI, but it is several moving parts to size, upgrade and secure. Raw ClickHouse is a columnar database; you still design schemas, retention and a query front-end. OpenObserve is a single product (Rust binary or HA role set) that stores telemetry as Parquet, queries logs with SQL, and can put files on local disk or S3-compatible object storage. On this shared VM without Docker it was practical to drill with release binaries. That is why the trio here is Loki, VictoriaLogs and OpenObserve.

Facts come from GitHub releases and LICENSE files, project docs, advisory records (GitHub Security Advisories, OSV, cve.org), and a loopback drill of Loki v3.7.8, VictoriaLogs v1.53.0 and OpenObserve v1.1.0 (the downloaded binary reported openobserve v1.1.0-rc3 on -V; noted honestly below). Vendor benchmark numbers in VictoriaLogs marketing pages are not repeated here as independent results.

The short version

Decide the index shape first. Loki indexes stream labels and stores compressed chunks (typically in object storage), then scans matching chunks with LogQL. VictoriaLogs indexes log fields for LogsQL full-text and analytics, with a strong single-binary path and an optional cluster. OpenObserve writes Parquet (columnar) and queries with SQL (and PromQL for metrics), as a logs/metrics/traces platform rather than a log-only database.
Grafana Loki (grafana/loki) current line is v3.7.8 (17 September 2026, 9:21 PM IST), with v3.6.17 on the same day for the 3.6 line. Default project licence AGPL-3.0-only (with Apache-2.0 exceptions listed in LICENSING.md). CNCF landscape lists Grafana Loki; there is no separate Graduated/Sandbox project page like Harbor’s. Pair it with Grafana for UI.
VictoriaLogs (VictoriaMetrics/VictoriaLogs) is at v1.53.0 (1 October 2026, 4:50 PM IST). Apache 2.0 for the OSS single-node and cluster builds. Separate enterprise binaries exist under VictoriaMetrics’ commercial terms. Default listen port in docs is 9428; retention defaults to 7 days unless you change -retentionPeriod.
OpenObserve (openobserve/openobserve) is at v1.1.0 (14 October 2026, 6:17 PM IST), after the v1.0.x line in September 2026. AGPL-3.0 for the open-source edition; an enterprise edition uses a commercial EULA. Single-node uses SQLite plus local disk or object storage; HA needs PostgreSQL, NATS and object storage.
Cardinality is the trap that fills disks and burns query CPU. Loki punishes high-cardinality labels. VictoriaLogs welcomes high-cardinality fields but warns against putting them in stream fields. OpenObserve’s stream and index settings decide what you pay for in Parquet and metadata. Retention and object-storage layout decide the invoice more than the logo on the binary.
Pipeline choice is out of scope here, but a messy Fluent Bit or OTel Collector config will punish every backend equally; fix shipping before you blame LogQL or SQL.
Security: Loki fixed a 2026 ruler path-traversal bypass in 3.6.4+ (CVE-2026-21726). OpenObserve published a large advisory batch in early September 2026 (several critical/high, including CVE-2026-63645 on older lines); run 1.0+ / 1.1 and read the GHSA pages before exposing UI. VictoriaLogs OSS advisories on the dedicated repo were empty on fetch day; still patch from changelog.

Where things stand on 15 October 2026

Dates are GitHub release published_at, converted from UTC to IST (UTC+5:30). Licences are from LICENSE / LICENSING files on the default branch. Prereleases and operator-only tags are not treated as the current server line.

Project

Release

Date (IST)

Notes

Licence

Grafana Loki (grafana/loki)

v3.7.8

17 September 2026, 9:21 PM

Current 3.7 line

AGPL-3.0-only (exceptions in LICENSING.md)

Grafana Loki

v3.6.17

17 September 2026, 5:11 PM

Current 3.6 line

AGPL-3.0-only

Grafana Loki

v3.7.4 / v3.6.13

24 July 2026

Earlier mid-year patches on both lines

AGPL-3.0-only

VictoriaLogs (VictoriaMetrics/VictoriaLogs)

v1.53.0

1 October 2026, 4:50 PM

GitHub releases/latest

Apache 2.0

VictoriaLogs

v1.52.1

1 October 2026, 11:45 PM

Patch on 1.52 line published after 1.53.0

Apache 2.0

VictoriaLogs

v1.51.1

18 August 2026, 11:59 PM

Prior 1.51 patch

Apache 2.0

OpenObserve (openobserve/openobserve)

v1.1.0

14 October 2026, 6:17 PM

Binaries via downloads.openobserve.ai (GitHub assets empty)

AGPL-3.0

OpenObserve

v1.0.4

24 September 2026, 5:27 PM

Last 1.0 patch before 1.1

AGPL-3.0

OpenObserve

v1.0.0

11 September 2026, 11:53 AM

First 1.0 stable tag

AGPL-3.0

Practical notes. Loki keeps two minor lines hot; know whether your Helm chart tracks 3.7 or 3.6 before reading an advisory. VictoriaLogs version numbers move quickly on the 1.x line; the dedicated GitHub repo dates from 6 July 2025, with the oldest listed release v1.25.0 on 7 July 2025, 5:28 AM IST. OpenObserve’s GitHub release page points to openobserve.ai/downloads rather than attaching binaries on the release itself. GitHub stars on research day were about 29,019 (Loki), 22,373 (OpenObserve) and 2,372 (VictoriaLogs); stars measure attention, not fitness for your retention policy.

Timeline

Date (IST)

Event

16 April 2018

grafana/loki repository created on GitHub

20 November 2019, 11:17 AM

Loki v1.0.0 released

7 December 2021, 3:54 PM

Loki default licence switched to AGPL-3.0 (git history; see LICENSING.md)

2 February 2023

openobserve/openobserve repository created

6 July 2025

VictoriaMetrics/VictoriaLogs repository created (dedicated home)

7 July 2025, 5:28 AM

VictoriaLogs v1.25.0 (oldest release listed on that repo)

16 April 2026, 3:00 AM

Loki advisory GHSA-497x-rrr9-68jp / CVE-2026-21726 published (fixed in 3.6.4)

4 to 17 September 2026

OpenObserve publishes a dense set of security advisories on the 0.90 to 0.92 lines

11 September 2026

OpenObserve v1.0.0

17 September 2026

Loki v3.7.8 and v3.6.17

1 October 2026

VictoriaLogs v1.53.0 (and v1.52.1 later the same day)

14 October 2026, 6:17 PM

OpenObserve v1.1.0

First question: what problem are you solving?

Before comparing query languages, the Pune review has to agree on which situation it is in.

Label-aligned Grafana stack. You already standardised on Prometheus labels, Grafana dashboards and maybe Tempo. You want log lines selectable by the same label set, cheap object-storage retention, and you accept that free-text search means scanning chunks after label match. Loki fits.

Log database with full-text and wide events. You need fast search across fields (including high-cardinality ones such as trace_id or payment_id), a small operations surface, and LogsQL rather than building Elasticsearch again. VictoriaLogs fits. Read the stream-field guidance carefully.

Columnar observability platform. You want SQL over Parquet, one UI for logs (and often metrics/traces), and object-storage-native files you could inspect with other Parquet tools. OpenObserve fits. Accept AGPL and the September 2026 security history as part of the upgrade discipline.

If the real pain is shipping logs (parsers, backpressure, OTLP), fix the pipeline first. If the pain is Elasticsearch cluster cost, do not assume Loki or VictoriaLogs is a drop-in; re-model labels or fields. If the pain is ClickHouse operations, prefer OpenObserve or a supported ClickStack only when the team already owns those components.

What each project actually is

Grafana Loki v3.7.8

Loki is a horizontally scalable, highly available, multi-tenant log aggregation system inspired by Prometheus. It does not full-text index every token of every line by default. It indexes labels that define a log stream, compresses log content into chunks, and stores chunks (and, with the recommended TSDB index, the index files too) in an object store such as S3, GCS, Azure Blob, or a filesystem for labs. Queries use LogQL: select streams by labels, then filter and parse lines, optionally derive metrics.

Deployment modes in current docs include single binary, HA monolithic, and microservices. Older Simple Scalable Deployment is deprecated toward removal in Loki 4.0 in favour of HA monolithic for many mid-size cases. Components you will meet in larger installs include distributor, ingester, querier, query-frontend, query-scheduler, compactor, index gateway and ruler. Multi-tenancy uses the X-Scope-OrgID header. Agents historically included Promtail; Grafana’s docs now push Grafana Alloy (and many teams still use Fluent Bit, Vector or the OTel Collector with a Loki exporter).

Licence: AGPL-3.0-only by default, with listed Apache-2.0 paths in LICENSING.md (clients, several pkg/ packages, production/, tools/). That matters for SaaS wrappers and for legal review in Indian product companies that redistribute modified servers.

VictoriaLogs v1.53.0

VictoriaLogs is VictoriaMetrics’ log database: resource-focused, single binary for many installs, with a documented cluster mode (vlinsert / vlselect / vlstorage style via -storageNode). Every log needs a message field (default _msg), may carry _time, and belongs to a _stream built from configured stream fields. VictoriaLogs indexes fields for full-text and structured filters. LogsQL combines filters (word, phrase, stream selectors, time) with pipes for stats, extract, sort and more.

Storage is per-day partitions under -storageDataPath (default victoria-logs-data). Retention defaults to 7 days (-retentionPeriod); you can also cap by disk bytes or filesystem percent. Object storage is not the primary single-node design the way it is for Loki; tiering is often partition attach/detach plus rsync/rclone patterns described in the docs. Ingestion protocols include JSON line, Loki, OpenTelemetry, Elasticsearch bulk-compatible, Syslog, Journald, Datadog and Splunk-oriented endpoints. Built-in web UI and a Grafana plugin are documented.

Licence: Apache 2.0 on the OSS repo. Enterprise binaries and flags (mTLS extras, autocert, and related) are separate; trial licences are offered by VictoriaMetrics. Treat vendor claims such as “up to 30x less RAM than Elasticsearch or Loki” as vendor benchmarks, not as numbers measured in this post.

OpenObserve v1.1.0

OpenObserve is a Rust-built observability platform for logs, metrics and traces (plus RUM and related features in current marketing). Data lands in streams, is written as Parquet, and is queried primarily with SQL (DataFusion stack in project history), with PromQL for metrics. Architecture docs describe five node roles in HA: Router, Ingester, Compactor, Querier, Scheduler. Single-node mode uses SQLite for metadata and either local disk or object storage for Parquet. HA mode requires Kubernetes, PostgreSQL, NATS and object storage; queriers are described as stateless readers of the file list plus Parquet.

Ingesters buffer in WAL and memtable, flush local Parquet, then upload merged files to object storage on configured intervals and size thresholds. Compactors merge small files, enforce retention and maintain the file list. The open-source edition is AGPL-3.0; enterprise builds use a commercial EULA, with downloads from the same downloads host. GitHub releases for v1.1.0 attach no artefacts; you fetch from downloads.openobserve.ai.

How the three index models feel in an incident

At 9:40 PM IST a Pune on-call gets a spike in UPI collect failures. With Loki, the first move is a tight label selector ({namespace="payments",job="collect-api"}) for the last fifteen minutes, then line filters for UPI or a parsed bank_code. If someone added payment_id as a label last quarter, the stream list is already noisy and the incident query pays for that mistake. With VictoriaLogs, the same engineer can search level:error UPI or payment_id:="pay_..." without inventing labels, as long as stream fields stayed stable. With OpenObserve, they open SQL against the stream, filter on columns, and may join mental context from a traces view if the team also ingested OTLP spans into the same product. None of these replaces a good runbook; each changes how expensive a messy schema becomes at 9:40 PM.

Object storage changes the failure mode. Loki and OpenObserve HA put durability in the bucket: a lost ingester disk hurts in-flight data more than historical Parquet or chunks. VictoriaLogs single-node puts durability in partitions on disk; backup and attach/detach become part of the SRE checklist, similar in spirit to database volume snapshots. Teams that already operate MinIO should read the earlier MinIO alternatives post before assuming the bucket layout is free.

Comparison tables

Shape and operations

Question

Grafana Loki

VictoriaLogs

OpenObserve

Primary shape

Log aggregation inspired by Prometheus

Log database (single node or cluster)

Observability platform (logs + metrics + traces)

Index model

Label index; scan chunks

Full-text / field index

Columnar Parquet + metadata/file list

Query language

LogQL

LogsQL

SQL (logs/traces); PromQL (metrics)

Typical dependencies

Object storage; optional caches; Grafana for UI

Local disk partitions; optional vl* cluster topology

SQLite or PostgreSQL+NATS; disk or object storage

Install paths

Binary, Helm, microservices

Single binary; cluster flags; Docker/K8s in docs

Binary, Docker, Helm HA

Licence (OSS)

AGPL-3.0-only

Apache 2.0

AGPL-3.0

Built-in UI

Via Grafana

Yes (plus Grafana plugin)

Yes

Object storage

First-class chunks + TSDB index

Secondary (backup/tier patterns)

First-class Parquet in HA / optional in local mode

Ingestion and query

Question

Loki

VictoriaLogs

OpenObserve

Push API

Loki push (/loki/api/v1/push)

JSON line, Loki-compatible, OTLP, others

HTTP JSON / OTLP-oriented ingest APIs

Stream identity

Label set

_stream from _stream_fields

Organization + stream name

Full-text

After label select (line filters, parsers)

Native field/token search

SQL + full-text keys / indexes per stream settings

Metrics from logs

LogQL metric queries; ruler

LogsQL stats pipes; vmalert patterns

SQL aggregations; metrics pipeline separately

Multi-tenancy

X-Scope-OrgID

AccountID / ProjectID headers

Organizations, RBAC in product

Storage, retention and cost levers

Lever

Loki

VictoriaLogs

OpenObserve

Hot path

Ingester memory + recent chunks

Local partitions

WAL / memtable / local parquet

Long retention

Object storage lifecycle + Loki retention/compactor

-retentionPeriod, disk caps, partition detach

Stream retention + compactor deletes

Cost driver

Label cardinality, chunk volume, query scan bytes

Disk IO, partition count, bad stream fields

Parquet volume, query fan-out, metadata DB

Compression

Chunk compression

Strong columnar-style compression in engine

Parquet columnar compression

High cardinality behaviour

Pattern

Loki

VictoriaLogs

OpenObserve

trace_id as label/stream field

Harmful (stream explosion)

Harmful if in _stream_fields; fine as ordinary field

Avoid naive partition keys that explode file counts

trace_id as line/field content

OK; filter after stream select

OK; indexed field search

OK; store as column; index settings matter

user_id / payment_id

Prefer structured metadata / parsers, not labels

Prefer ordinary fields

Prefer columns, watch distinct indexes

Symptom

Huge index, slow tail, ingester pain

vl_streams_created_total spikes; RAM/disk growth

Many tiny Parquet files; heavy compaction

Symptom to shape

Symptom

Lean towards

“Our Grafana users already think in Prom labels”

Loki

“We replaced Elasticsearch once and refuse another JVM cluster”

VictoriaLogs or OpenObserve

“Legal wants Apache 2.0 on the log store”

VictoriaLogs

“We want SQL and Parquet on MinIO”

OpenObserve

“We already run ClickHouse and HyperDX”

ClickStack path (out of scope here)

“Ninety days must be cheap”

Loki or OpenObserve on object storage; VL with tiered partitions

A worked example (invented)

Company: “Sahyadri Ledger Labs” in Pune (invented). Workload: UPI collect and mandate APIs, about 8,000 requests/second at peak IST evenings, JSON logs with payment_id, merchant_id, bank_rrn, trace_id. Requirement: 14 days hot interactive search, 90 days investigate-on-demand, audit export for a handful of dispute cases per week. Team: six platform engineers, already run Grafana, Prometheus and MinIO.

If they pick Loki. Keep labels low cardinality: job, env, namespace, cluster. Put payment_id and trace_id in the line or as structured metadata, not as labels. Store chunks on MinIO. Use LogQL for incident windows; accept that broad free-text over 90 days is a scan budget problem. Align with the existing Grafana habit.

If they pick VictoriaLogs. Set _stream_fields to stable identity (job, env, host or pod labels that do not churn per request). Ingest JSON with payment fields as ordinary fields. Use LogsQL payment_id:="pay_..." for disputes. Plan disk for 14 to 90 days or detach cold partitions to cheaper volumes. Apache 2.0 simplifies legal.

If they pick OpenObserve. Create a payments_api log stream, send JSON, query with SQL for disputes, put Parquet on MinIO for the 90-day tier. Budget for PostgreSQL+NATS if they need HA. Schedule upgrades after reading the September 2026 advisories; do not expose the UI without TLS and SSO.

Recommendation for this invented team: start with VictoriaLogs if legal prefers Apache 2.0 and the primary job is field search on payment identifiers; pick Loki if Grafana-wide label discipline is already strong and object-storage cost is the CFO’s only slide; pick OpenObserve if the roadmap wants one SQL UI across logs and traces and the team accepts AGPL plus platform complexity.

Security

Verified against GitHub advisory APIs, OSV and cve.org. NVD HTML pages often return 403 from this environment, so this post links cve.org and project GHSA pages instead.

Grafana Loki

GHSA-497x-rrr9-68jp / CVE-2026-21726 (medium, published 16 April 2026 IST): path-traversal bypass in the ruler API via double-encoded namespace; fixed in 3.6.4. Current 3.7.8 / 3.6.17 include the fix line.
Older GHSA-grj5-8x6q-hc9q / CVE-2021-36156: historical ruler path traversal, fixed in 2.3.0.
Shared controls: authenticate multi-tenant gateways, restrict ruler and config HTTP surfaces, pin chart versions, monitor GitHub advisories for grafana/loki.

VictoriaLogs

On fetch day, the VictoriaMetrics/VictoriaLogs repo returned no GitHub security advisories. The parent VictoriaMetrics/VictoriaMetrics list included unrelated component issues (for example vmrestore path traversal CVE-2026-61625). Still read the VictoriaLogs changelog before upgrades.
Shared controls: bind to internal listeners, enable delete API only when required (-delete.enable), protect partition and force-merge endpoints with auth keys, put vmauth (or similar) in front for tenant isolation.

OpenObserve

Early September 2026 brought a dense advisory set on pre-1.0 lines. Examples (vulnerable ranges from GHSA pages; prefer v1.0.4+ / v1.1.0):

GHSA-5x2v-jg9q-g8qc (critical): SQL injection in gRPC StreamStats (< 0.91.0).
GHSA-9x7q-vmf6-6cm5 (critical): SSRF on alert destination save/update (< 0.91.0).
GHSA-v496-g5c9-vqxw / CVE-2026-63645 (high): unauthenticated /config/runtime exposing database credentials (<= 0.90.2).
GHSA-x5jp-879w-2mx2 (high): SQL injection in _values filter (< 0.92.0).
Several further high SSRF and cross-tenant issues on < 0.91.0 / < 0.92.0 lines (token listing, pipeline and annotation org checks, enrichment URL SSRF).

Shared controls: never expose OpenObserve UI or ingest to the internet without TLS and SSO; rotate root passwords from quickstart defaults; treat 0.9x as upgrade fuel, not production freeze; read each GHSA html_url before claiming “we are fine on latest”.

Decision guide

Situation

Lean towards

Why

Grafana + Prometheus label culture, object-storage retention

Loki

Same mental model; TSDB + chunks on S3/MinIO

Apache 2.0 required; field search and wide events

VictoriaLogs

OSS Apache 2.0; LogsQL; stream-field discipline

SQL + Parquet + one observability UI

OpenObserve

Productised columnar logs path

Already operate ClickHouse deeply

ClickStack / CH schemas (not this trio)

Reuse existing warehouse skill

Small team, one VM, mostly grep-like workflows

VictoriaLogs single binary

Low moving parts

Multi-tenant SaaS log product

Careful with AGPL (Loki/OO); VL + gateway

Licence and isolation design

Pune recommendation (invented). Run a two-week bake-off: identical Fluent Bit fan-out into Loki and VictoriaLogs on staging, measure disk and p95 query for payment_id lookups, then decide. Add OpenObserve only if SQL/Parquet and unified traces are on the quarterly roadmap. Do not keep three production backends.

Retention maths without fake precision

Do not trust slideware compression ratios for budget sign-off. Measure on your own JSON. Take one day of production logs from a single busy service, load them into a trial of each backend on identical hardware, and record: raw bytes in, bytes on disk or in the bucket, and p95 latency for three fixed queries (list errors for 15 minutes, fetch one payment_id, count errors by bank_code for 24 hours). Multiply the storage result by your retention days, then add object-storage PUT/GET costs if applicable. That workbook beats any “Nx cheaper” claim, including claims on VictoriaLogs docs that compare against Elasticsearch or Loki. Those vendor benchmarks are useful as a hint to test, not as a purchase number.

Also plan who may delete. Loki retention is usually policy-driven via the compactor. VictoriaLogs keeps delete APIs off until -delete.enable is set, which is safer against accidental wipe but must be enabled deliberately for GDPR erasure. OpenObserve stream retention and compactor jobs need an owner. Infinite retention with no delete path is how regulated fintech teams fail audits.

Checklist

Write down retention (hot days vs cold days) and the query that must stay interactive.
Classify every high-cardinality field as label/stream-field forbidden or ordinary field allowed.
Confirm licence with legal (AGPL vs Apache 2.0) before demos become production.
Pin exact versions in Git; avoid floating :latest.
Decide object storage (MinIO or cloud) versus attached disk; practise restore.
Put collectors behind backpressure limits; storage cannot fix a firehose alone.
Enable auth on UI and write paths; change default passwords.
Subscribe to GitHub advisories for your chosen repo.
Document delete/GDPR process (Loki compactor retention; VL delete API; OO retention jobs).
Rehearse an incident query on staging with production-like cardinality.

Common mistakes

Putting trace_id or payment_id into Loki labels “just for convenience”.
Leaving VictoriaLogs on default 7-day retention while promising finance ninety days.
Assuming OpenObserve GitHub release assets exist; forgetting downloads.openobserve.ai.
Running OpenObserve 0.9x after the September 2026 advisory wave.
Treating ClickHouse, ClickStack and OpenObserve as the same decision.
Comparing only ingest GB/day and ignoring query scan bytes.
Skipping TLS because “it is only internal”.
Using vendor “Nx cheaper than Elasticsearch” slides as capacity plans.
Building a second pipeline language per backend without standardising OTLP/JSON fields.
Never testing restore of object-storage prefixes or VL partitions until an AZ fails.

A drill I ran on 15 October 2026

Shared VM, no Docker. Port 8766 left for the HTML preview server. Binaries: Loki v3.7.8 (loki-linux-amd64.zip SHA-256 62aea42c9cba52cd1642b3666ab37019a0ce4c24ab50b07e85dccc8d812f7d61 matched release SHA256SUMS), logcli same release (44b790601963193df9cc496f0c8d6782e5d28c90754ca7a697e3f5683dad2588), VictoriaLogs v1.53.0 (victoria-logs-prod SHA-256 f174d6166e59192af9fa01caeb65fbdffa1da5fa3a171138a7528ce403397c87 matched release checksums), OpenObserve from the OpenObserve downloads opensource v1.1.0 linux-amd64 tarball (SHA-256 628fcadca54adf7bd9a033cc95a5e64c674ef0d573c09e01b3613f347012e5cd; no vendor checksum file on that URL; openobserve -V printed openobserve v1.1.0-rc3).

Listeners: Loki 127.0.0.1:18100 (gRPC 18101), VictoriaLogs 127.0.0.1:18110, OpenObserve defaulted to **0.0.0.0:18120** despite env attempts to prefer loopback (clients used 127.0.0.1 only). About 2:20 AM IST (14 October 2026 20:50 UTC on the box clock during the run).

Health. VictoriaLogs /health HTTP 200. Loki /ready HTTP 200 after a short warmup (first check 503). OpenObserve /healthz HTTP 200.
Loki push. POST /loki/api/v1/push with two lines for {job="payments-api",env="drill",host="blr-drill-1"} (UPI collect error and ok).
Loki query. logcli query '{job="payments-api"}' returned both lines with detected_level labels inferred.
VictoriaLogs ingest. POST /insert/jsonline with _stream_fields=job,env,host. Metrics showed vl_bytes_ingested_total{type="jsonline"} at 354.
VictoriaLogs query. LogsQL _time:1d * returned both events. _time:1d level:error returned the failure. Bare word error matched nothing useful because _msg was UPI collect failed for merchant (no token error); use level:error or message text deliberately.
OpenObserve ingest. Basic auth as quickstart root user; POST /api/default/payments_api/_json returned successful: 2.
OpenObserve search. First SQL call with start_time/end_time 0 failed (invalid time range). A second call with a microsecond window around now returned both rows via /api/default/_search.
Stop. All three processes killed; ports 18100/18110/18120 closed; 8766 untouched.

Surprises: OpenObserve binary version string lagged the download folder name (v1.1.0-rc3 vs v1.1.0); OpenObserve listened on all interfaces by default; VictoriaLogs word filters default to _msg, not every field. Not drilled: Loki microservices, VL cluster, OpenObserve HA (PostgreSQL/NATS), S3 backends, authentication hardening, or any exploit reproduction.

Artefacts under drill42/: binaries, configs, logs, query outputs, checksum notes.

Unlearn

Unlearn “logs storage is just Elasticsearch with a different logo”.
Unlearn putting request IDs into Loki labels because LogQL looks like PromQL.
Unlearn that default retention is “forever” (VictoriaLogs defaults to 7 days).
Unlearn that GitHub Releases always attach the binaries you need (OpenObserve).
Unlearn treating ClickStack and OpenObserve as interchangeable “columnar logs”.

Re-learn

Re-learn label versus field versus Parquet column as three different cost models.
Re-learn LogQL stream selectors before line filters.
Re-learn LogsQL stream fields versus searchable fields.
Re-learn OpenObserve single-node versus HA dependencies.
Re-learn advisory hygiene after Loki CVE-2026-21726 and the OpenObserve September 2026 batch.

Closing

Self-hosted log storage in 2026 is a retention and cardinality problem wearing a query-language costume. Grafana Loki keeps the Prometheus mindset: small label index, chunks on object storage, LogQL in Grafana. VictoriaLogs offers an Apache-licensed log database with LogsQL, wide events and a binary you can reason about on one host or grow into a cluster. OpenObserve brings Parquet and SQL as a full observability product, with AGPL and a sharper recent security patch story. ClickStack remains relevant when you already live in ClickHouse, but it is a stack, not a third peer binary. Learn which index you are buying. Unlearn infinite retention without an owner. Re-learn field discipline before the next traffic festival. Practise push and query on loopback. Apply one backend to production, and only then keep another month of logs.

Sources

Grafana Loki

VictoriaLogs

OpenObserve

ClickStack context (not selected as third peer)

Security records

Internal

comments powered by Disqus

Releted Posts

Container registries in 2026: revisit Harbor, Zot and CNCF Distribution before you push another image

Manoj Shukla
October 14, 2026

Picture a product engineering team in Bengaluru that runs about forty microservices on Kubernetes for a B2B payments product used by NBFCs across Karnataka and Maharashtra (an invented example, not a real client).

Manoj Shukla
October 12, 2026

Picture a payments and lending analytics platform in Hyderabad (an invented example, not a real client). Card authorisations and EMI schedules still land in PostgreSQL 16.

Manoj Shukla
October 12, 2026

Picture an ecommerce and last-mile logistics platform in Bengaluru (an invented example, not a real client). Order capture and inventory still run on PostgreSQL 16.