// the find
VictoriaMetrics/VictoriaLogs
Fast and easy to use database for logs, which can efficiently handle terabytes of logs
VictoriaLogs is a standalone log storage and query engine from the VictoriaMetrics team. It speaks Elasticsearch, Loki, Datadog, Syslog, OpenTelemetry, and Splunk ingest protocols, so you can drop it behind most existing log shippers without changing them. The target audience is teams running VictoriaMetrics for metrics who want a consistent operational story for logs without paying Datadog or running a full ELK stack.
The multi-protocol ingest layer is genuinely useful — you can point Fluent Bit or Promtail at it unchanged, which lowers adoption friction considerably. Storage compression and query performance track VictoriaMetrics' reputation: the benchmarks show credible numbers against Loki, and the architecture avoids Loki's chunk-based write amplification. The built-in `vlagent` handles Kubernetes pod log collection and file tailing with checkpoint persistence, so you don't need a separate Fluentd sidecar fleet for the common case. LogsQL has real aggregation pipelines (group-by, stats, math expressions) that PromQL users will find familiar — it's not just grep with timestamps.
LogsQL is a custom query language with no ecosystem — you can't carry PromQL, SQL, or Lucene knowledge into it, and the SQL-to-LogsQL and LogQL-to-LogsQL converters in the playground are a tell that the team knows this is friction. The cluster version is documented separately but there's no clear operational runbook for rebalancing or resharding as data grows; VictoriaMetrics' cluster docs are the implicit reference. At ~2000 stars the project is early-production; you'll hit rough edges and issues faster than you'd like if you're running multi-TB/day at scale. No native alerting integration — you need to pair it with vmalert or an external ruler, which adds operational surface even for simple log-based alerts.