Loki vs VictoriaLogs: which fits your log volume and query style
Choose Loki when your logs are mostly read by label and you already run object storage and a Grafana-centered stack. Choose VictoriaLogs when you need full-text search across message bodies, high-cardinality fields, or local disk without an object store. Both are built to cost less than Elasticsearch, but they make different bets: Loki indexes only the labels on each log stream and keeps compressed chunks in object storage such as S3, while VictoriaLogs stores data on local disk in a single directory and is queried with LogsQL. Loki fits if your team is comfortable with AGPLv3 and your query habit is to filter by stream labels and then scan the matching lines. VictoriaLogs fits if Apache-2.0 is a policy requirement, if analysts search free text across fields, or if your platform team would rather operate a single executable than an object store plus Loki's components.
Loki is the stronger fit when your platform already has an approved object store, when logs are grouped cleanly by a small set of labels, and when dashboards, Explore and alerting already live in Grafana. Its licence is AGPLv3, which Grafana Labs applied to Loki and its other core projects from April 20, 2021, so legal review should happen before adoption. Loki also has no built-in authentication layer, so you will need an authenticating reverse proxy in front of it if you use multi-tenancy. VictoriaLogs fits when fields such as request IDs, user IDs or trace identifiers are common and must be searchable, because Loki's documentation steers high-cardinality values away from labels. Confirm with VictoriaMetrics which features your edition includes, since enterprise support and features are sold separately.
The decision turns on five questions: how your engineers query logs day to day, how long you must keep them, where your storage platform is headed, what your license policy allows, and which skills your team already has. Ask a few real users to write the queries they run most often, then test them on both stores with a copy of production volume. Check retention separately: Loki's compactor keeps logs indefinitely until retention is enabled, while VictoriaLogs defaults to 7 days, optionally capped by disk usage. Confirm that your current shippers, such as Promtail, Grafana Alloy or Fluent Bit, can push to the Loki-compatible endpoint on VictoriaLogs before you plan a migration, because that compatibility reduces the cost of a switch.
Which scenario points to which log store
This table matches common logging situations to the store that usually fits better, and notes where the other option is still reasonable. Read each row as a starting point, then confirm the condition against your own volumes, query patterns and licensing policy.
| Scenario | Better fit | Reason and where the other option still works |
|---|---|---|
| Security investigations that need free-text search across raw messages | VictoriaLogs | VictoriaLogs is queried with LogsQL, which supports full-text search and field extraction at query time. Loki indexes only labels, so unindexed text is scanned at query time. Loki still works if investigations mostly start from known labels such as host, namespace or service. |
| Logs with many unique field values, such as request IDs or user IDs | VictoriaLogs | The VictoriaLogs FAQ states that Grafana Loki does not support high-cardinality labels, while VictoriaLogs lists high-cardinality fields among its supported features. Loki remains suitable if these values can stay out of labels and be filtered from log content. |
| Kubernetes platform that already runs S3-compatible object storage | Loki | Loki keeps compressed chunks and its index in object storage, and its documented production stores include Amazon S3, Google Cloud Storage and Azure Blob Storage. VictoriaLogs stores data on local disk in a single directory, so it adds disk planning to the platform. VictoriaLogs still fits if the cluster already has fast local volumes and no object store. |
| Multi-tenant log access across several teams | Loki | Loki is multi-tenant when auth_enabled is true and identifies tenants with the X-Scope-OrgID header. Loki has no built-in authentication, so an authenticating reverse proxy such as OAuth2 Proxy or Pomerium is required in front of it. VictoriaLogs also lists multitenancy, so confirm the access model you need against its documentation. |
| Strict Apache-2.0 policy for every server-side component | VictoriaLogs | VictoriaLogs single-node and cluster versions are released under the Apache License 2.0. Grafana Loki is licensed under AGPLv3 after Grafana Labs moved its core projects from Apache 2.0 in April 2021. If your policy allows AGPL for internal services, Loki is a valid choice. |
| Small cluster or single host with modest log volume | VictoriaLogs | VictoriaLogs runs as a single zero-config executable and its capacity scales with CPU, RAM, disk I/O and disk space. Loki's monolithic mode is also a single binary, so the answer depends on whether you need object storage at all. Confirm volumes against the Loki monolithic guidance before choosing. |
| Teams that need logs kept for a long period by default | Loki | Loki retention is disabled by default, so logs are kept until retention_enabled is set and retention rules are defined. VictoriaLogs defaults to 7-day retention, optionally capped by disk usage. Both stores need a written retention policy, and long retention on VictoriaLogs means sizing local disk for it. |
| Existing Promtail, Grafana Agent or Grafana Alloy collectors | Either, with a caveat | VictoriaLogs accepts logs at the Loki-compatible push endpoint /insert/loki/api/v1/push, so existing collectors can be pointed at it. Loki is the native target for these shippers, and migrating collectors is still a configuration change you should test. Illustrative case: a team with Alloy pipelines can trial VictoriaLogs on one cluster before moving all sources. |
| Teams that depend on the Grafana stack and LogQL dashboards | Loki | Loki uses LogQL and is the native Grafana log source. VictoriaLogs provides a Grafana plugin for building dashboards and uses LogsQL, so existing LogQL queries and alert rules must be rewritten. Keep Loki if dashboards and alerting are already built around LogQL. |
How Loki and VictoriaLogs differ in storage design
Both products avoid the full-text index cost of Elasticsearch, but they spread data across different places. Loki splits work between a label index and object storage, while VictoriaLogs keeps everything in one local directory. The cards below show what each choice means for backups, capacity planning and day-to-day operations.
Index model and what gets indexed
Loki indexes only labels for each log stream, not the log lines themselves, so queries on message text scan the chunks that match the label selection. VictoriaLogs builds full-text search over log content and supports high-cardinality fields. Check your most common queries first: if your team searches for free text or unique IDs during incidents, Loki's label-only model will feel slow for that work. Test it with a sample of your real logs.
Where chunks and index live
Loki keeps compressed chunks and its index in object storage such as S3, Google Cloud Storage or Azure Blob Storage. The docs describe S3-compatible stores and the local filesystem as supported but not typically recommended for production. VictoriaLogs stores data on local disk, so disk throughput, free space and the storage class you choose set its limits. Ask your team which object store or disk tier you will run before you compare costs.
Single-binary and cluster shapes
Loki's monolithic mode runs as one binary for smaller volumes, and its simple scalable mode splits read, write and backend targets. The docs say simple scalable mode is being deprecated and will be removed in Loki 4.0, so new deployments should plan for monolithic or microservices. VictoriaLogs runs as a single zero-config executable, and its cluster mode spreads logs across vlstorage nodes. Confirm which shape your daily log volume needs before you size hardware.
Per-day partitions and retention
VictoriaLogs stores data in per-day partitions and defaults to 7 days of retention, optionally capped by disk usage. Loki retention is handled by the compactor and is disabled by default, so logs are kept until you enable retention_enabled and set rules. Each Loki stream rule must be at least 24 hours. Test both systems with your real retention target, because a missed setting in Loki can keep data far longer than planned.
Backups and capacity planning
In Loki, the object store holds most data, so backups usually depend on object storage versioning and replication, while the compactor and index are separate moving parts to monitor. In VictoriaLogs, the data directory on local disk is the backup target, and capacity depends on disk I/O and free space on each node. Ask your team who owns object store lifecycle rules, and whether restore tests have been run for either option.
Operating the index and compactor
Loki's TSDB index and compactor-driven retention are two separate services that must run and be watched, and both affect how fast old data is removed. VictoriaLogs bundles ingestion, storage and query in one process per node, which means fewer moving parts but a single node failure affects the data it holds. Count how many services your on-call team must monitor, and compare that with the disk and bandwidth limits you can live with.
How the query languages, retention and ingestion compare
This table compares the query, storage, retention, tenancy and ingestion behavior of Grafana Loki and VictoriaLogs for the same log workload. Read each row as a question to answer on your own data, because the speed and resource claims come from the VictoriaLogs project and need a test before you rely on them.
| Capability | Grafana Loki | VictoriaLogs |
|---|---|---|
| Query language | LogQL, which selects streams by labels and then filters or parses log lines | LogsQL, which supports full-text search, analytics and field extraction at query time |
| Indexing scope | Only labels for each log stream, not log contents | Full-text indexing of log contents on local disk |
| High-cardinality fields | The VictoriaLogs FAQ states Loki does not support log fields with many unique values as labels | Listed as a supported feature in the VictoriaLogs documentation; confirm behavior at your field counts |
| Where data lives | Compressed chunks and the index in object storage such as S3 | Single data directory on local disk with per-day partitions |
| Default retention | Disabled until retention_enabled is set in the compactor, so logs are kept indefinitely | 7 days by default, optionally capped by disk usage |
| Multitenancy | Enabled when auth_enabled is true, identified by the X-Scope-OrgID header | Listed as a supported feature in the VictoriaLogs documentation |
| Live tailing and alerting | Live tailing and alerting depend on the Loki and Grafana stack you already run | Live tailing supported, with alerting through vmalert |
| Grafana integration | Native data source from Grafana Labs | A Grafana plugin is available for dashboards; confirm feature parity for your panels |
| Shipper support | Promtail, Grafana Alloy, Fluent Bit, Fluentd, the Docker logging driver and OpenTelemetry over HTTP | Loki-compatible push endpoint for Promtail, Grafana Agent and Alloy, plus Filebeat, Fluent Bit, Fluentd, Logstash, OpenTelemetry, Vector and others |
Can your existing collectors point at either store without rework?
Most existing collectors can keep running, but the destination change is not the whole job. Promtail, Grafana Agent and Grafana Alloy can send logs to VictoriaLogs through its Loki-compatible push endpoint at /insert/loki/api/v1/push, so the first change is usually the url in the client configuration. Loki natively accepts Grafana Alloy, Fluent Bit, Fluentd, OpenTelemetry logs over HTTP and the Docker logging driver, so a team already on those shippers can keep them and change only the endpoint and tenant settings. Fluent Bit, Fluentd, Logstash, Vector and OpenTelemetry also have their own VictoriaLogs ingestion paths, which you should confirm against the VictoriaLogs documentation for your exact agent version.
The labels are where rework hides. Loki treats each label as an index key, so teams often add labels such as pod, host or request ID to make queries fast. VictoriaLogs indexes full text and supports high-cardinality fields, so those values can usually stay as ordinary fields, but the same labels will still be sent as fields and will still be queried differently. Before cutting over, run both pipelines side by side on a representative service and test three things: that field names and timestamps map as expected, that label cardinality on the Loki side does not change the shipper behavior you rely on, and that the same time window returns matching counts for the queries your alerts and dashboards use. Query translation from LogQL to LogsQL is a separate task covered elsewhere on this page.
What the AGPLv3 and Apache-2.0 licenses mean for each platform
Grafana Loki is licensed under AGPLv3. Grafana Labs announced on April 20, 2021 that Loki and its other core projects would move from the Apache License 2.0 to AGPLv3, so the AGPL terms are the ones to plan around for current releases. The license attaches to the software you run, whichever deployment mode you choose.
- Copyleft on modifications: patching Loki, such as changing the compactor or an ingester behavior, and distributing the modified code triggers the source-sharing duties of AGPLv3, so track every change.
- Unmodified use: running the published binary or container image without changes carries the lightest set of obligations, although distributing it to others still has conditions to review.
- Version history: builds released under Apache 2.0 before the change keep those terms, so the license of a deployed build depends on its version.
- Stored data: the license concerns the software, not the logs in your object storage bucket, but confirm with counsel how the terms apply to any hosted or managed arrangement.
Confirm the license text that ships with the exact release you plan to deploy.
VictoriaLogs single-node and cluster versions are released under the Apache License 2.0, according to the VictoriaLogs documentation and the VictoriaMetrics/VictoriaLogs GitHub repository. Apache 2.0 is a permissive license that allows use, modification and redistribution, including inside proprietary products, subject to notice and attribution terms. It also includes an express patent license from contributors, which counsel should review in your context.
- Single-node and cluster parity: both deployment forms carry Apache 2.0, so moving from one to the other does not change the license of the code.
- No network source-offer clause: Apache 2.0 has no provision requiring you to offer modified source to users who interact with the software over a network.
- Notice and change records: redistributing the software or derivatives requires keeping license notices and documenting changes as the license requires.
- Mixed stack: the license of the VictoriaLogs binary does not decide the license of the shippers, plugins or dashboards you add, so check each component separately.
Confirm the license file in the exact release tag you intend to deploy before you write the policy.
AGPLv3 adds a network-use provision to the GPL. If you modify the program and users interact with it remotely over a network, you may have to offer those users the corresponding source of your modified version. The practical questions are whether your changes count as modifications and who counts as a user. Internal and external use can lead to different readings of the clause, and the analysis belongs to counsel.
- Unmodified internal use: running Loki unchanged for your own engineers and security staff is the case where the clause is least likely to matter, because no modified source is involved.
- Modified internal use: a patched Loki used only by employees still raises the question of whether internal staff count as users under the clause, so record the modifications and the audience.
- Externally offered services: if customers, partners or other outside parties query a modified Loki through a service you run, the network-use duty is more likely to apply, and you would need to offer them the modified source.
- Provider-operated deployments: where a provider runs Loki for you, define in the written scope which party operates it and who its users are, since that affects the analysis.
Document the modification record, the user population and the delivery model before you treat internal use as settled.
VictoriaMetrics offers enterprise support and enterprise features for VictoriaLogs, and enterprise releases are publicly available with a free trial license, according to the VictoriaLogs documentation. The open-source builds remain under Apache 2.0, so the commercial offer covers support and enterprise features on top of that code. Ask what the enterprise license grants and restricts before you depend on any feature that appears only in those builds.
- Support agreement: support is bought from the vendor under its own terms, so request response commitments and escalation paths in writing before you rely on them.
- Enterprise feature list: the documentation refers to enterprise features without a full list on the same page, so ask for the feature list that applies to the exact build you plan to run.
- Trial license: the free trial lets you evaluate enterprise builds before committing; confirm its duration and conditions with the vendor.
- Commercial terms: an enterprise license may carry usage, redistribution or term conditions that the Apache 2.0 build does not, so read them before deployment.
- Recurring cost: support and license fees recur, so include them in total cost of ownership alongside the effort your own team spends operating the system.
Request the enterprise license text and the support terms in writing before you start a pilot.
The license questions that matter most are tied to your exact version and delivery model, so a short written record prevents surprises later. Use the Grafana Labs licensing page for Loki's terms and the VictoriaLogs documentation for the Apache-licensed builds, then have counsel review the answers for your context. Record the license, the release tag and the deployment model together so the decision can be audited.
- Version under license: record the release tag or image digest you run, since Loki's license change dates from April 20, 2021 and older builds may carry different terms.
- Modifications: keep a list of patches, custom builds and wrappers, including any proxy placed in front of the service.
- Audience: list who uses the log store, including internal staff, customers, partners and auditors.
- Shippers and plugins: check the license of each agent, plugin and dashboard tool in the pipeline.
- Support terms: confirm whether vendor support or enterprise features are part of the plan and whether their terms change any obligation.
Bring this record to counsel and to the vendor before you sign or deploy.
What drives the running cost of each log store
The running cost of Loki and VictoriaLogs sits in different places, so compare them by component rather than by a single license line. Both are open source at no license fee for the core product, which means the money goes to infrastructure, staff time and any paid support you choose. For Loki, the largest recurring items are compute for the write and read paths, object storage capacity and request charges, and the compactor that applies retention. Loki stores compressed chunks and its index in object storage such as S3, so your bill follows how many bytes you keep and how many requests the querier makes against them. For VictoriaLogs, the recurring items are local disk capacity and I/O, CPU and RAM for ingestion and queries, and the node count if you move to cluster mode, which spreads logs across vlstorage nodes.
Retention is the lever that moves both models most. Loki retention is disabled by default, so logs are kept indefinitely until retention_enabled is set, which means an unconfigured cluster grows without limit. VictoriaLogs defaults to 7 days of retention and can also be capped by disk usage, so its footprint is bounded by configuration you set on each node. Ask your team to model the daily ingest volume at your real peak, then multiply by the retention period you need for audit and incident work. Staff time is the cost most often left out of a quote. Plan for upgrades, dashboard and alert maintenance, and monitoring of the log store itself. Loki's Simple Scalable deployment mode will be removed in Loki 4.0, so a deployment built on it will need a migration project later.
Paid support is the one recurring line that is not a hardware cost. VictoriaMetrics offers enterprise support and enterprise features for VictoriaLogs, with enterprise releases publicly available under a free trial license. Grafana Enterprise Logs is a separate product from open source Loki, so it carries its own contract. Before you request a quote from either vendor, ask for the support tier, the metric used for pricing, whether it is per node, per volume or per user, what the trial license covers, and what upgrade and security-patch commitments are included. From DeployOpen, a quote follows from a written scope that lists the storage backend, the node layout, the retention rules and the monitoring you expect your team to keep.
How to move from Loki to VictoriaLogs, or back, in order
This sequence moves log ingestion from one store to the other without a gap in coverage, so the team can confirm query parity and alert behavior before any source stops sending to the old system. It ends with a retired store and a documented rollback path.
Inventory shippers, labels and alert rules
Start by listing every log source, the collector that ships it (Promtail, Grafana Alloy, Fluent Bit, Fluentd, OpenTelemetry Collector or the Docker logging driver), and the label scheme each source emits. Record which dashboards, LogQL alert rules and saved queries depend on each label, and which fields are high-cardinality. Owners sign off on the inventory before any change is made. Done means every source has a named owner, a collector type and a list of dependent dashboards and alerts.
Confirm the push path with a test source
Point one non-critical collector at the VictoriaLogs Loki-compatible push endpoint, /insert/loki/api/v1/push, while it keeps its existing Loki destination. Check that Promtail, Grafana Alloy or Fluent Bit records arrive with the expected fields and that the stream labels survive intact. Done means the team can search the test records in VictoriaLogs and confirm that no field was dropped or renamed in transit. If the collector is not Promtail, Grafana Alloy or another shipper listed in the VictoriaLogs documentation, confirm support with the vendor before going further.
Run both stores in parallel on the same traffic
Configure the collectors to send each source to both Loki and VictoriaLogs at the same time, so the two stores hold the same events for the same window. Size the VictoriaLogs host or cluster against the actual ingestion rate observed during the test, not against vendor claims. Keep Loki as the system of record until the comparison in the next step passes. Done means both stores show matching event counts for each source over an agreed window, and disk and CPU headroom on the VictoriaLogs side has been measured.
Translate and validate queries and alerts
Rewrite each LogQL dashboard panel and saved query as LogsQL, and move each alert rule to vmalert so it evaluates against VictoriaLogs. Run old and new queries over the same time range and compare the results, paying attention to how label matchers, line filters and parsed fields behave. The Grafana plugin for VictoriaLogs can host the rebuilt dashboards. Done means every alert has been fired in a controlled test, each dashboard panel returns matching results, and the owners have signed off on the rebuilt saved views.
Decide retention overlap and historical data handling
Set the VictoriaLogs retention period, which defaults to 7 days and can also be capped by disk usage, to match the operational and compliance needs of each log class. Decide whether history must be searchable after cutover. Loki chunks and index in object storage do not transfer into VictoriaLogs' local per-day partitions, so any history that must stay queryable needs to remain in Loki for its retention window, or be exported and kept in an archive under the team's own policy. Confirm retention obligations with the compliance owner. Done means a written retention decision exists per log source, with the Loki retention setting for the archive period recorded.
Cut over each source in turn
Move sources to VictoriaLogs one group at a time, starting with the lowest-risk sources, by removing the Loki destination from their collector configuration. After each group switches, watch ingestion, query latency and alert firing for a period the team agrees on before moving the next group. Keep a configuration change ready that restores the Loki destination for each group. Done means each source shows steady ingestion in VictoriaLogs, its alerts evaluate correctly, and the rollback change has been tested.
Retire Loki after the agreed overlap
When every source has run on VictoriaLogs through the agreed overlap and no rollback has been needed, stop the Loki write path and disable its compactor and ingestion components. Keep the object storage bucket for the retention period decided earlier, then delete it under the documented retention policy. Remove the authenticating reverse proxy in front of Loki if it is no longer used. Done means no collector writes to Loki, the archive is handled as the retention decision requires, and the runbook reflects the new system.
Where implementation projects for each log store usually run long
The longest delays in a Loki project usually come from design decisions made before the first log line is shipped. On the Loki side, plan the object storage layout (S3, Google Cloud Storage or Azure Blob Storage are the recommended production stores), the TSDB index configuration (the recommended index store for Loki 2.8 and newer), and the compactor settings that apply retention. Retention is disabled by default, so a team that never sets retention_enabled keeps logs indefinitely, which turns a storage estimate into an open-ended cost. Choose a deployment mode early: monolithic, simple scalable or microservices. Simple scalable mode is being removed in Loki 4.0, so a new build that adopts it now should confirm the migration path with Grafana Labs before go-live. Loki also has no built-in authentication, so an authenticating reverse proxy such as nginx, HAProxy, OAuth2 Proxy or Pomerium must be designed, tested and monitored as part of the deployment, along with auth_enabled and the X-Scope-OrgID tenant header if tenants are needed. Confirm the exact release you plan to deploy against the Loki v3.7.8 release notes.
VictoriaLogs shifts the work toward disk and partition planning. It runs as a single executable that stores data on local disk in one directory with per-day partitions, so the team must size disk I/O and disk space for the ingest rate and the retention window. The default retention is 7 days, optionally capped by disk usage, and a team that wants 30 days or more must set retention deliberately and test what happens when the disk cap is reached. If volume outgrows one node, the cluster mode spreads logs across vlstorage nodes, and sizing those nodes, the insert and select tiers, and the load balancer is a separate design exercise. Authentication and multitenancy also need design work: VictoriaLogs supports multitenancy, but the access model in front of it, and which tenants see which streams, must be settled before dashboards are shared. Validate the release against the current VictoriaLogs v1.53.0 line before you pin versions.
Across both stores, four delays recur. The first is label design on Loki: labels chosen for convenience, such as request IDs or user IDs, create too many streams and force a redesign of queries and shipper configuration. The second is unplanned retention, where the team discovers after months that nothing was ever deleted or that a disk cap dropped data it needed for an investigation. The third is dashboard rebuilds: LogQL dashboards do not translate to LogsQL, and a team that migrates collectors but not panels will spend weeks rewriting queries and alert rules, although Promtail, Grafana Agent and Grafana Alloy can keep pointing at VictoriaLogs through its Loki-compatible push endpoint. The fourth is access control gaps, where a proxy or tenant boundary is added after logs from several teams are already mixed. Ask any implementation partner for a written scope that covers label or field schema, retention policy, the access layer and dashboard migration, and confirm each item against your own compliance and data residency requirements.
What buyers and engineers ask before choosing a log store
Which log store costs less to run, Loki or VictoriaLogs?
Neither has a cost you can read off a price list, because both are open source and the spend is in the infrastructure and the people who run it. Loki's main recurring cost is object storage for compressed chunks and the index, plus the compute for its write, read and compactor components. VictoriaLogs keeps data on local disk in a single directory, so its recurring cost is mostly disk capacity, CPU and RAM on the nodes you run. The VictoriaLogs FAQ says it usually needs less RAM and storage for the same logs, but those are the vendor's own claims. Run both against a sample of your own log volume and retention, then compare the monthly storage, compute and staff hours you would actually pay for. Ask any commercial partner for a written quote tied to a fixed scope.
How long does it take to migrate from Loki to VictoriaLogs?
The duration depends on how many collectors, dashboards, alert rules and retention windows you have, and no supplied fact gives a timeline, so confirm the estimate against your own inventory. The switch is easier at the shipping layer than at the query layer. VictoriaLogs accepts pushes from Promtail, Grafana Agent and Grafana Alloy through the Loki-compatible endpoint at /insert/loki/api/v1/push, so you can often repoint collectors first and run both stores in parallel. Queries are the harder part, because LogQL dashboards and alert rules must be rewritten in LogsQL. Historical data does not move automatically, so decide early whether you keep old Loki data until it expires or backfill it.
Can a platform team run a log store without outside help?
A platform team with Linux, object storage and dashboard experience can run either product, but the work differs. Loki asks for an object store, a deployment mode decision, and a compactor and retention setup that is disabled by default, so you must turn retention on deliberately. Loki also has no built-in authentication, so you need an authenticating reverse proxy in front of it. VictoriaLogs is a single zero-config executable with local storage and a built-in web UI, which usually means fewer moving parts for a small team. Whether you staff this internally or bring in an implementation partner depends on your team's capacity and on how much custom work you need. DeployOpen plans, implements and documents self-hosted platforms in your own infrastructure under a written, fixed scope, and ongoing support is available as a retainer.
What do security and compliance teams need to check for each option?
Security and compliance teams should look at authentication, tenant isolation, encryption, retention and access logging before approving either product. Loki supports multi-tenancy when auth_enabled is true, identified by the X-Scope-OrgID header, but it has no built-in authentication layer, so an authenticating proxy such as nginx, HAProxy, OAuth2 Proxy or Pomerium is required. VictoriaLogs supports multitenancy and its enterprise edition is offered by VictoriaMetrics with enterprise support, so check which features your use case needs and whether they sit in the Apache-2.0 build. Both store data in your environment, which changes the evidence you must produce. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications; independent auditors and certification bodies do that.
Is Loki or VictoriaLogs a better fit for a small cluster?
For a small cluster, VictoriaLogs is often the simpler choice, because it runs as a single executable on local disk with a default retention of 7 days, optionally capped by disk usage. Loki's monolithic mode fits modest volumes, and the Loki docs describe it as handling up to about 20 GB of logs per day, but it still expects object storage for production use. The Loki docs note that S3-compatible stores and local filesystems are supported but not typically recommended for production, which affects small installs that want to avoid a cloud bucket. If your volume is small and you want the fewest dependencies, test VictoriaLogs first. If you already run object storage and want decoupled scaling, Loki may suit you better.
Does the 1000x faster claim apply to my workload?
The 1000x figure is the VictoriaLogs FAQ's own claim for typical full-text search queries, and it may not match your queries, data shape or hardware. The speed difference depends on query type, field cardinality, retention window, disk I/O and how much of the data each query scans. Loki indexes only labels, so queries filtering on labels are fast, while free-text searches over message contents scan chunks, and that cost grows with the data searched. VictoriaLogs builds full-text capability into its storage design and supports high-cardinality fields, which Loki's documentation does not present as a supported label pattern. Replay a representative set of your slowest real queries on both stores with your own data before drawing any conclusion.
Which license terms matter when choosing between Loki and VictoriaLogs?
The license decides what you can change, redistribute and charge for, so read it before you build on either product. Grafana Loki is licensed under AGPLv3, a change Grafana Labs announced on April 20, 2021 when it moved Loki and its other core projects from Apache License 2.0. Under AGPLv3, if you modify Loki and offer it to users over a network, you must make the modified source available to them, which matters if you run a customized build for internal or external users. VictoriaLogs single-node and cluster versions are released under Apache License 2.0. Have your legal or open-source review team confirm how these terms apply to your deployment model.
How DeployOpen helps you choose, implement or migrate a log store
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so the Loki or VictoriaLogs decision is tested against your environment before anything is built. Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we scope
- We document your log sources, daily volume, retention needs and which teams query logs today.
- The written scope states which shippers, such as Promtail, Alloy or Vector, must be pointed at the chosen store.
- We confirm your object storage or local disk plan, deployment mode and tenancy model before estimating deliverables.
- Quotes follow from the written scope, so you can compare the two options on the same assumptions.
How we build
- We deploy the chosen store in your cloud account, data center or air-gapped network, using your chosen topology.
- We configure retention, authentication through a reverse proxy where needed, and tenant separation for each team.
- We migrate or parallel-run collectors so existing pipelines keep shipping while queries are rebuilt in the new language.
- We test ingestion, query behavior, alerting and failure handling against scenarios agreed in the scope.
How we hand over
- You receive architecture notes, configuration records and runbooks written for your own operations staff.
- We document the LogQL or LogsQL dashboard and alert rewrites, so queries can be maintained after handover.
- Handover includes a walkthrough of backup, restore, retention and upgrade steps for your environment.
- We record open items and the vendor facts you should confirm before production cutover.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- A retainer can cover version upgrades, retention changes, new log sources and periodic security testing of the log platform.
- If you later decide to switch stores, we scope that migration in writing using the same method as the first build.
