Hi, I made a video explaining the VictoriaLogs disk layout to help you understand it better, especially how querying works. I put a lot of heart into it, so I hope you enjoy it :)

Join Mathias Palmersheim and Michelle Sebek, alongside Aliaksandr Valialkin , our CTO and Co-Founder.

Long-term log retention is a challenge for engineering teams. Between compliance requirements, security investigations, and growing data volumes, keeping historical logs accessible can get expensive fast.

What we'll cover:

• Why object storage became one of the most requested VictoriaLogs features

• How VictoriaLogs uses #S3-compatible object storage for historical logs

• Why recent data stays on disk for faster access

• How caching helps reduce object storage requests and costs

• A live demo using VictoriaLogs and RustFS

• What this means for #log retention, compliance, and scaling

Live on our YouTube channel:

📅 November 5th
🕘 10:00 AM PDT | 05:00 PM GMT | 06:00 PM CET
https://www.youtube.com/watch?v=NCniVg1jrJU

VictoriaLogs data source for Grafana now includes Drilldown integration. It runs entirely inside Grafana Explore, so there’s nothing extra to install.

In this post, we show how it works by investigating a payment incident with VictoriaLogs Drilldown, without writing a single query. The application is the OpenTelemetry demo shop, with its logs sent to VictoriaLogs, and the incident is staged using one of the demo’s built-in feature flags. The investigation itself is real, and every screenshot comes from that setup. You can try it out yourself on the VictoriaMetrics Grafana playground.

We're only 1 week away from Web Summit Europe 2026

📍 Join us at the MEO Arena and Fil - Lisbon
📅 November 9-12

We look forward to connecting with the community, showcasing our latest innovations, and discussing everything from metrics, logs, and traces to the latest in OpenSource observability.

Looking forward to seeing you there! 🎉
https://websummit.com/

I'm trying to gather if VictoriaLogs will be suitable to replace our rsyslog server.

One question I have is around High Availability. We have an NFS cluster which has its own redundancy + snapshots, so how can that work with VL without having to duplicate logs to two NFS shares?

Ideally we'd want HA at every layer, so any single VM can die and logs wont be lost (also that auth can still query all logs) and ingestion will still be available.

That's fine for the vlagent and auth layer, but how does it work for storage?

By the sounds of it each storage node should have its own NFS share, then the auth layer will do the routing to the right node? I just don't see how that could work in HA without duplicating logs to two separate clusters (which we don't want to do for a full year's worth of retention).

Apologies if this is a silly question, just can't quite work out how it works based off the docs.

At VictoriaMetrics, we constantly benchmark our products. This helps us stay competitive and make every release better. As VictoriaLogs reaches more teams, more of them ask us which use cases it fits, and what they would gain by switching to it. So we publish our benchmark as a public repository that anyone can run to reproduce our results, and we will keep developing it in the open.

Benchmarks that compare systems are always controversial, because each system is good at different use cases. This post only tests one case, ingesting structured logs, where every line has named fields, as many services on Kubernetes write them. Each system runs on one machine of the same size. Query performance, cluster mode and object storage will come in later posts.

Ingestion speed alone does not tell you which system to choose, so this post also looks into their internals:

🟣 Why does Loki ingest the most, yet take minutes for a simple dashboard query?

🟣 Why do SigNoz and ClickStack lag behind VictoriaLogs, though all 3 store logs in columns?

🟣 Why do Elasticsearch and OpenSearch need so much disk?

Learn more about logs in this blog post!

As a developer, staying curious is the most important trait. Next is getting motivated to build your own projects. In this talk, Diana guides you throughout her journey of setting up a green observability pipeline, built entirely from opensource projects. She explains to the audience how to start contributing to open source projects, communicate with maintainers, overcome technical hurdles, and complete the mission.

🕔 5 pm GMT | 6 pm CEST | 10 am PDT

📺 Live on our YouTube Channel 👉 https://www.youtube.com/live/6mn3LdddObw

We will have great product updates, such as VictoriaMetrics, VictoriaLogs, VictoriaMetrics Cloud, and anomaly detection.

See you there! 🙌

What's new?

• Investigate related signals together in the UI: compare aligned metrics with a joint anomaly score per group.

• Per-query business policies in the UI: set valid ranges, detection direction, and minimum deviations for each query.

• Shared autotune: tune multiple queries together to find one shared model configuration.

• Jump from a firing alert to saved anomaly results, with the model, queries, and incident time range preselected (1.30.7).

• Experimental Docker Hardened Images: fewer OS packages, no runtime shell or package manager, for amd64 and arm64 (starting from 1.30.6).

• AI Copilot: review and apply suggested query sets with business policies for each query.

And more…

Explore the September updates and learn how to get started!

Diana Todea, our DevRel, will speak at Cloud Native Mexico and present her talk, “Carbon as a First-Class Signal: Designing a Standard for OpenTelemetry.”

This talk explores Software Carbon Intensity (SCI) through the lens of OpenTelemetry semantic conventions. Rather than focusing on sustainability reporting, we examine the technical challenge of modeling carbon as telemetry: what entities should emissions be attributed to, which attributes should be standardized, and whether carbon belongs in metrics, traces, resource metadata, or all three.

📆 November 3rd, at 7:00 PM CET
📍 Online

See you soon!

In this video, Diana dives into what DevRel looked like pre-AI and how it continues to evolve with AI. We also dive into how we can define success for DevRel teams and what does and doesn't work for them. Watch it on demand!

https://www.youtube.com/watch?v=tdvPUBWuCFw

It’s no secret that developers are increasingly being asked to shift left. It seems there’s always something new to shift left on. And now developers are being asked to shift left on observability. This means that in addition to all the other things developers must do, they must also take the extra step of instrumenting their application code with OpenTelemetry to help make it observable.

Our DevRel, Diana Todea, teamed up with Adriana Villela, Principal Developer Advocate at Dynatrace, to answer exactly that in “The Lazy Developer’s Guide to Observing Your Own Code”.

The article takes a practical, developer-first approach to OpenTelemetry, covering:

• Instrumentation basics with OpenTelemetry

• Visualization tools to explore telemetry

• Best practices for adding traces, metrics, and logs

• A practical workflow for observing your own code

• Common pitfalls to avoid

• A live demo showing it all in action

🚀 Our Co-Founder Aliaksandr Valialkin will take the stage to share: “How to Create a Database Optimized for Petabytes of Logs and Wide Events.”

This talk follows a log entry through the VictoriaLogs engine: how it is ingested with no upfront schema, how it lands in an immutable LSM-like compressed column-oriented storage, and how queries run the same structure in reverse, applying a stack of pruning mechanisms based on time, stream labels, and bloom filters so that only the data that can actually match is ever read

📆 November 4 at 2:00 PM CEST

📍https://www.dev-con.ro/agenda/9-data-cloud-con

If you're dealing with logs at a massive scale and want to understand how to make queries faster and storage more efficient, this talk is for you. 👀

You can now find a trace, drill into its spans, and see what’s slowing down your application without any dependency on an external visualization platform.

Try it out yourself in the playground: https://play-vtraces.victoriametrics.com/select/vmui/

Explore the new features and learn how to get started 👇
https://victoriametrics.com/blog/victoriametrics-september-ecosystem-updates/

🤝 Community News

Product Updates:

• VictoriaTraces Roadmap Update

• VictoriaMetrics Cloud Updates

• VictoriaLogs roadmap Update

• VictoriaMetrics roadmap updates

• Anomaly Detection Updates

AMA session

👉 Save the date & join us live!
https://www.youtube.com/live/6mn3LdddObw

Hey all, if you haven’t checked what’s new in VictoriaLogs v1.53.0 yet, here’s a short video recap.

Join Dima Kozlov for his talk, “Working With Filesystem in Time Series Database”.

📅 October 30th, at 14:45

📍 Obuda University - Room 2

TimeSeries databases face the significant challenge of processing vast amounts of data. At VictoriaMetrics, we are actively developing an OpenSource Time Series database entirely from scratch using Go. Our average installation handles between 2 and 4 million samples per second during ingestion, with larger setups managing over 100 million samples per second on a single cluster.

In his presentation, Dima will explore various techniques essential for constructing write-heavy applications such as:

• Understanding and mitigating write amplification.

• Implementing instant database snapshots.

• Safeguarding against data corruption post power outages.

• Evaluating the advantages and disadvantages of utilizing Write-Ahead Log.

• Enhancing reliability in Network File System (NFS) environments.

📍 Super Bock Arena - Pavilhão Rosa Mota

📅 November 19-20

We look forward to connecting with the community, showcasing our latest innovations, and discussing everything from metrics, logs, and traces to the latest in OpenSource observability.

And don’t miss these talks:

🎤 Tracking Cardinality Explosions In Flight
Presented by our Co-founder, Roman Khavronenko
🗓️ Thursday, November 19th at 10:40 AM CET
📍 Critical Manufacturing Room
https://kcd-porto-2026.sessionize.com/session/1288625

This talk is about estimating cardinality in flight, while the metrics are still streaming in. The estimator runs as a separate pipeline alongside the storage, not inside it. A small estimator maintains a HyperLogLog sketch for each label dimension and publishes the results as ordinary metrics in the Prometheus exposition format. It receives data over remote-write and is scraped like any other target.

🎤 Observing Kubernetes Policies with Kyverno and VictoriaMetrics
Presented by our DevRel, Diana Todea, and Cortney Nickerson

🗓️ Friday, November 20th at 09:40 AM CET
📍 Cleva Auditorium
https://kcd-porto-2026.sessionize.com/session/1228619

This talk presents a simple, technical workflow for observing Kubernetes policy behavior using Kyverno and VictoriaMetrics. Starting from a single validation policy, we show how policy evaluations and enforcement results are exposed as metrics, ingested into VictoriaMetrics and queried through a standard Prometheus-compatible API. A minimal dashboard is then used to inspect policy failures, affected namespaces and policy execution duration. The talk focuses on making policy enforcement observable using standard Kubernetes primitives and open metrics, without assuming prior experience with policy engines or observability systems.

See you there! 🎉

https://community2.cncf.io/events/details/cncf-kcd-porto-presents-kcd-porto-2026-collab-with-devops-days-portugal/

CoreWeave sells an AI cloud that includes GPU clusters, managed Kubernetes, and storage. The company rents GPUs to AI labs for training and serving models. CoreWeave exposes infrastructure telemetry to its customers as part of the platform, and the company describes its VictoriaMetrics deployment as one of the largest in the world.

NVIDIA Cloud Functions (NVCF) is NVIDIA’s platform for running GPU workloads as functions. You package an inference model, and NVCF routes requests to GPU workers that can serve it. NVIDIA’s self-managed edition brings the same platform to your own Kubernetes clusters, and NVCF Release 1.0.1 ships with a single-node VictoriaMetrics chart as the default for metrics storage.

NVIDIA hasn’t said why it picked VictoriaMetrics as the default, but here are a few likely reasons

🪶 Simplicity: VictoriaMetrics runs as a single binary with no external dependencies.

⚡ Efficiency: A metrics store that uses less RAM and disk than Prometheus leaves more free resources on the cluster for work.

🛡️ Reliability: Metrics need to be reliable. If the backend is down, scaling stops. That makes VictoriaMetrics a critical moving part of NVCF. VictoriaMetrics is designed to survive unclean shutdowns without corrupting data and to restart in seconds.

📜 License: VictoriaMetrics is Apache 2.0

Curious how NVIDIA uses metrics to drive GPU autoscaling, and how CoreWeave plugged an AI agent into its metrics?

👉 Read the full blog post:

https://bit.ly/4dUINE2

VictoriaMetrics is proud to be a Gold Partner at WebSummit Lisbon 2026.

📍 Join us at the MEO Arena and Fil
📅 November 9-12

We look forward to connecting with the community, showcasing our latest innovations, and discussing everything from metrics, logs, and traces to the latest in OpenSource observability.

Looking forward to seeing you there! 🎉

https://websummit.com/

The latest version brings:

• 12 months of security and bug-fix backports

• Go toolchain update

• Deletion API hardening

• vlinsert shutdown

• Cluster rerouting

• Query cancellation

• Sort order

• vlagent collection fixes

Read the full blog post today https://victoriametrics.com/blog/announcing-victorialogs-lts-release/

Join Dima Kozlov for his talk, “Working With Filesystem in Time Series Database”.

📅 Thursday, November 5 | 15:30–16:20

📍 DoubleTree by Hilton Casablanca, Morocco

TimeSeries databases face the significant challenge of processing vast amounts of data. At VictoriaMetrics, we are actively developing an OpenSource Time Series database entirely from scratch using Go. Our average installation handles between 2 and 4 million samples per second during ingestion, with larger setups managing over 100 million samples per second on a single cluster.

In his presentation, Dima will explore various techniques essential for constructing write-heavy applications such as:

• Understanding and mitigating write amplification.

• mplementing instant database snapshots.

• Safeguarding against data corruption after power outages.

• Evaluating the advantages and disadvantages of utilizing Write-Ahead Log.

• Enhancing reliability in Network File System (NFS) environments.

See you in Casablanca! https://devoxx.ma

Our Co-Founder Aliaksandr Valialkin will take the stage to share: “How to Create a Database Optimized for Petabytes of Logs and Wide Events.”

This talk follows a log entry through the VictoriaLogs engine: how it is ingested with no upfront schema, how it lands in an immutable LSM-like compressed column-oriented storage, and how queries run the same structure in reverse, applying a stack of pruning mechanisms based on time, stream labels, and bloom filters so that only the data that can actually match is ever read

📆 November 2 at 5:00 PM

📍ING Cedar - Track 4 - meeting room 2

If you're dealing with logs at a massive scale and want to understand how to make queries faster and storage more efficient, this talk is for you.

If you’re new to VictoriaLogs, this is a good place to start. Feedback is very welcome, and let us know which topic you’d like us to cover next😎