Sumo Logic vs Grafana Loki: which fits your log analytics
Choose Sumo Logic if your team wants managed search, dashboards and alerting without running servers, and accepts that logs live in a SaaS service you do not operate. Choose Grafana Loki if you already have object storage, Grafana skills and the capacity to run an authenticating proxy, retention and upgrades yourself. Most readers arrive because of a renewal, a residency rule or a lock-in concern, so start by asking which of those is driving the change and whether the answer can be met by a managed service at all.
The decision turns on three questions. First, operating capacity: Loki has no built-in authentication, so you must place a reverse proxy such as nginx, HAProxy, OAuth2 Proxy or Pomerium in front of it, and you must choose a deployment mode from the monolithic, simple scalable or microservices options, bearing in mind that simple scalable mode is being deprecated. Second, data location: Loki writes compressed chunks and its index to object storage, so the residency answer depends on which bucket and region you select, while Sumo Logic stores data in its own cloud. Third, indexing model: Loki indexes only labels and scans log content at query time, so high-cardinality fields that your analysts search every day need to be designed carefully, and LogQL is a different language from Sumo Logic's query syntax.
Which option fits which situation
This table maps common situations to the better fit between Sumo Logic and self-hosted Grafana Loki. Read each row as a starting point, then confirm the points marked in the reason column against your own volumes, staffing and compliance obligations. Loki is a log store and query layer, not a SIEM, so security-focused needs point elsewhere.
| Situation | Better fit | Reason |
|---|---|---|
| Small team with no platform staff | Sumo Logic | Loki needs someone to run object storage, the compactor, the query path and an authenticating proxy, and Sumo Logic hides that work. |
| Existing Grafana estate with Prometheus metrics | Grafana Loki | Logs can sit beside metrics and traces in the same Grafana instance, data sources and dashboards you already maintain. |
| Strict data residency or air-gapped networks | Grafana Loki | Loki runs in your own accounts or data centers, so logs never leave the network you specify, which Sumo Logic's SaaS model does not offer. |
| High-cardinality application logs | Depends on design | Loki indexes labels only, so high-cardinality fields must stay out of labels or queries become slow; confirm your label strategy before choosing. |
| Security-focused SIEM needs | Sumo Logic or a security platform | Loki has no correlation rules, threat detection or case management, so a SIEM layer such as Wazuh or OpenSearch must be added. |
| Long retention with cost predictability | Grafana Loki | Object storage holds the data and retention is set in the compactor, but storage and operator time still recur and must be sized. |
| Need for vendor-supported SLAs and enterprise SSO | Sumo Logic | Loki is AGPLv3 open source with no bundled support, and SAML and SCIM sit in Grafana Enterprise, so ask whether you need that contract. |
Where logs live and who controls access
Sumo Logic keeps your logs in the regions it operates, while a self-hosted Loki keeps chunks, indexes and access decisions inside storage and networks you control. The cards below cover the decisions that follow from that split, and the work that falls to your team once Loki is running.
Data location and object storage
With Sumo Logic, log data sits in the SaaS region you select and the provider operates the storage. With Loki, compressed chunks and the index live in the object store you configure, so location is your decision. Grafana's storage docs recommend Amazon S3, Google Cloud Storage or Azure Blob Storage for production, and note that MinIO and local filesystems are supported but not typically recommended for production. Confirm which store, region and encryption settings your residency rules require before choosing.
Hosting model and deployment mode
Loki's monolithic mode suits smaller daily volumes, while simple scalable and microservices modes handle larger volumes and split read, write and backend paths across components. Each mode changes who patches, scales and monitors the cluster. Note that the Loki docs say simple scalable mode is being deprecated and will be removed with Loki 4.0, so plan for microservices or a monolithic deployment on your own hosts or Kubernetes.
Identity integration and its limits
Grafana's authentication options include LDAP, generic OAuth, Entra ID, Okta, GitHub, GitLab, Google OAuth, auth proxy and JWT in all editions. SAML, team sync, active sync and SCIM provisioning are available only in Grafana Enterprise and Grafana Cloud. If your identity policy requires SAML or automated SCIM deprovisioning, budget for Enterprise or confirm that an OAuth or proxy path meets the same control objective.
Loki proxy as a trust boundary
Loki has no built-in authentication layer, so the authenticating reverse proxy you place in front of it becomes the access control point. Tenant identity comes from the X-Scope-OrgID header when auth_enabled is true, and that header can be spoofed if the proxy does not set or strip it. Test that clients cannot reach Loki directly, and that the proxy enforces the tenant mapping you intend.
Compliance evidence you prepare
Sumo Logic may provide its own compliance documentation, but a self-hosted Loki stack puts evidence work on your team: access reviews, retention settings, encryption configuration and change records. DeployOpen can prepare systems, controls and evidence for an assessment, but independent auditors issue any report or attestation. Ask your auditor early which Loki settings and proxy logs they will sample.
Hardening the Grafana front end
Grafana is the query and dashboard layer for Loki, and its security hardening docs cover secure and SameSite cookies, a Content Security Policy, Trusted Types, hiding the version from unauthenticated users and authentication on the metrics endpoint. Grafana configuration also needs a MySQL or PostgreSQL database for production and high availability, since SQLite does not scale. Include that database in your access and backup scope.
What the AGPLv3 license means for Loki
Grafana Labs moved Loki from the Apache License 2.0 to the GNU Affero General Public License v3 (AGPLv3) on April 20, 2021, and Loki is licensed under AGPLv3 today. For most teams that run Loki unmodified for internal log analytics, the practical question is narrower than the license text suggests: AGPLv3 is a copyleft license, so if you modify Loki and make the modified version available to users over a network, such as a log search service offered to other business units, customers or partners, you should expect to publish the source of those modifications under the same license. Confirm with counsel whether your internal use, your patches and any hosted service you provide fall inside or outside that obligation.
Grafana Enterprise is the non-AGPL commercial option that Grafana Labs offers alongside the open-source distribution, and the Grafana Labs licensing page explains how the editions and their terms differ. Ask Grafana Labs in writing which terms apply to Loki and to Grafana Enterprise Logs, and whether a commercial license would change your obligations. Plugins, SDKs and agent software carry other licenses, so check each component you deploy, including Grafana Alloy and any shipper you choose, rather than assuming the whole stack shares one license.
Your Sumo Logic subscription is governed by its own order form and terms of service, not by an open-source license. Review the data ownership, data location, termination, export and usage clauses in your contract to see what you can take out and what you are restricted from doing. Then compare those obligations with what AGPLv3 requires of you, so that the decision reflects both sides of the trade.
Choosing a Loki deployment mode by daily volume
Choose the Loki deployment mode from your measured daily log volume, not from the size of your Sumo Logic bill. Before you pick a mode, pull the ingested bytes per day for the sources you plan to move, using the usage figures you already have in Sumo Logic and a sample of raw log sizes from your collectors. Count peak days, not averages, and add the sources you expect to onboard within your planning horizon. Monolithic mode runs all Loki components in a single binary and suits volumes up to about 20 GB of logs per day, according to the Loki deployment modes documentation. Above that level, the documentation points to a separate read, write and backend split.
Simple scalable mode separates read, write and backend targets and is documented as approaching 1 TB per day. Treat that figure as an upper reference from the docs, not a guarantee for your workload, because query shape, label cardinality and retention all change real cost. The same documentation states that simple scalable mode is being deprecated and will be removed with the Loki 4.0 release. A build that starts now on simple scalable mode would face a forced migration. For sustained volumes above the monolithic range, plan for the microservices mode, which the docs describe for very large clusters, and confirm current guidance with Grafana Labs or your implementation partner before you commit.
Write down the mode, the daily volume it was sized for, and the trigger that would prompt a change, such as a sustained rise past the monolithic range or a new high-volume application. Ask Grafana Labs to confirm the supported path after simple scalable mode is removed, and ask what the microservices topology implies for operating staff, object storage access and the authenticating proxy you must place in front of Loki. Those choices also drive the cost of running the stack, so settle them before the cutover plan is drawn up.
What a self-run Loki stack costs to operate
A self-run Loki stack replaces one subscription with several smaller cost lines, each paid to a different party. The cards below separate the Sumo Logic spend you would retire from the infrastructure, proxy, upgrade and staff work you would take on, so a quote can be compared line by line.
Sumo Logic subscription and usage
This is the recurring line you would retire, and it is driven by ingestion, retention and search usage rather than by server count. Before comparing, pull your current invoice and separate ingest, storage and search charges, since a Loki stack reduces some of them and not others. Ask Sumo Logic for the contract terms covering exit, notice periods and any data export obligations, because those set when the cost actually stops.
Object storage for chunks and index
Loki keeps compressed log chunks and its index on object storage, so storage cost scales with retained volume and the retention rules you configure. Amazon S3, Google Cloud Storage and Azure Blob Storage are the recommended production stores, and their pricing is set by the provider and your region. Ask for a projection that uses your actual daily volume and retention period, and confirm request and egress charges for read-heavy dashboards.
Compute for write and read paths
Sizing follows the deployment mode you choose, which the Loki docs tie to daily volume: monolithic for small volumes, simple scalable for larger ones, and microservices for very large clusters. Write-path compute handles ingestion, while read-path compute handles query load from many dashboards. Simple scalable mode is deprecated and will be removed in Loki 4.0, so a quote for it should include a migration plan to microservices or another supported layout.
Grafana database and load balancer
Production Grafana needs MySQL 8.0 or later or PostgreSQL 12 or later, because SQLite does not scale for production or high availability. High availability uses two or more active-active Grafana servers behind a load balancer. Confirm whether the quote includes managed database backups, failover testing and the alerting configuration needed to avoid duplicate notifications, since Grafana Live has limits in high availability.
Authenticating proxy and identity work
Loki has no built-in authentication, so an authenticating reverse proxy such as nginx, HAProxy, OAuth2 Proxy or Pomerium must sit in front of it, and tenants are separated with the X-Scope-OrgID header. Grafana's SAML, team sync, active sync and SCIM provisioning are limited to Grafana Enterprise and Grafana Cloud. Price the proxy build, tenant mapping and any Enterprise license needed for your identity provider as separate line items.
Grafana Cloud and Enterprise reference points
Grafana's published pricing gives a reference point, not a quote for your environment. Grafana Cloud has a free tier, a Pro tier starting with a 19 US dollar monthly platform fee plus usage, and an Enterprise tier with a minimum commitment of 25,000 US dollars per year. Use these figures to frame a comparison with usage-based Sumo Logic billing, and ask any vendor to state what its quote includes beyond the platform fee.
Upgrades on the Grafana cadence
Grafana ships major releases once a year in April or May, minor releases every other month and patch releases at least monthly. Each minor release is supported for 9 months, and the last minor release of a major version for 15 months, so the upgrade calendar is continuous work. Loki releases also need testing against your proxy and dashboards. Ask the provider to commit to a patch cadence and to name who tests and rolls back each upgrade.
Staff time and outside support
Operating Loki means someone owns on-call response, capacity reviews, retention changes and incident work, and that cost recurs whether the stack is run in-house or by a partner. Outside support can be a retainer covering upgrades and monitoring, or a fixed-scope build. Request a written split of responsibilities, the hours assumed per month, and the escalation path. DeployOpen quotes follow from a written scope, so ask any provider, including DeployOpen, for that scope before comparing totals.
How a move from Sumo Logic to Loki works at a high level
The sequence moves log collection and search to Loki in stages, so each source is proven on the new stack before Sumo Logic is switched off, and history is handled as its own plan.
Inventory sources, volumes and searches
The platform owner lists every Sumo Logic collector, source category, forwarder and scheduled search, and records the daily ingestion volume per source and the retention each team expects. Labels for Loki are chosen from this list, since Loki indexes only stream labels and not every field. The step is done when each source has an owner, a daily volume estimate and a named set of dashboards and alerts that depend on it. Ask your Sumo Logic contact or your own billing data for current ingestion figures, since those numbers drive the deployment mode choice.
Size and deploy the Loki stack and Grafana
The platform team picks a Loki deployment mode based on the daily volume from the inventory, then deploys Loki on object storage with Grafana beside it, using a production object store and a MySQL or PostgreSQL database for Grafana configuration. Loki's documentation places monolithic mode at small volumes and notes that simple scalable mode is being deprecated, so the choice should be checked against the current docs before build. The step is done when Loki accepts a test stream, returns it in Grafana and the object store holds the chunks.
Put an authenticating proxy in front of Loki
Because Loki has no built-in authentication, the security team places an authenticating reverse proxy such as nginx, HAProxy, OAuth2 Proxy or Pomerium in front of it, and sets the tenant header that the proxy passes through. The team confirms that unauthenticated requests are refused and that each tenant can read only its own streams. The step is done when a test user without rights is blocked at the proxy and a user with rights reads only the permitted tenant.
Dual-ship collectors to Alloy or Fluent Bit
The collection team adds Grafana Alloy or Fluent Bit alongside the existing Sumo Logic collectors so each source writes to both platforms during a parallel run. Labels are set in the shipper so that streams match the inventory and do not carry high-cardinality values. The step is done when the same events arrive in Sumo Logic and Loki for each source, and the event counts match within an agreed tolerance that the team writes down before the run starts.
Rebuild searches and dashboards in LogQL
Analysts translate the most important Sumo Logic searches and dashboards into LogQL queries and Grafana panels, using the labels set in the previous step. Loki does not import Sumo searches directly, so each query is rewritten and checked against the same time window in both tools. The step is done when each critical dashboard and alert shows the same results on new data in both systems, and the owners sign off on the differences.
Set retention in the compactor for new data
The platform team enables retention in the Loki compactor, which is disabled by default, and sets rules globally, per tenant or per stream selector, with each rule at least 24 hours. Retention values come from the inventory and any compliance requirement the data owners confirm. The step is done when the compactor configuration is in version control and a test stream is removed after its rule period.
Plan history separately and cut over
Historical data needs its own plan because the Sumo Logic browser CSV export is capped at 100,000 rows per search, so older logs are either exported in shorter time ranges, kept in read-only archive form or left in Sumo Logic until the retention period ends. Once the parallel run and the history decision are signed off, collectors stop sending to Sumo Logic, and the Sumo Logic subscription is ended after the agreed retention window. The step is done when all sources write only to Loki and the archive plan is documented. For the export mechanics, see the migration sibling page only as a next read on how the exit works.
Who runs the stack day to day
Running Loki yourself means your own engineers own every layer: the Loki components, the object store that holds compressed chunks and the index, the Grafana servers, the log shippers and the authenticating proxy in front of Loki. Loki has no built-in authentication, so the proxy is part of the platform you must patch and monitor.
- Upgrades: Track Loki releases and Grafana releases separately. Grafana publishes patch releases at least monthly, and Loki's deployment mode you choose affects how much a version change touches.
- Object storage backups: Object storage holds your logs and index, so the team must define replication or backup, test restores and document recovery time for the chosen store.
- Proxy patching: nginx, HAProxy, OAuth2 Proxy or Pomerium sits on the data path. Assign a named owner for its certificates, authentication configuration and security updates.
- Alert routing and retention reviews: Retention is disabled by default, so someone must set it, review it against policy and confirm the compactor runs. Alert routing for Grafana needs extra configuration in high availability to avoid duplicate notifications.
- Named owners: Assign an owner for each item above before go-live, along with an on-call rotation for the log pipeline itself.
Confirm with your security and compliance leads which retention periods and access reviews they require, and whether your staffing covers this rotation around the clock.
Keeping Sumo Logic means Sumo Logic operates the search platform, storage, scaling and service availability. Your team still owns collectors, source configuration, access roles, saved searches, dashboards and monitors, and it owns the cost of the subscription and the credits it consumes.
- Platform operations: Sumo Logic runs the service, so patching and capacity sit with the vendor. Your team does not carry an upgrade calendar for a log platform.
- Collectors and sources: Your team still maintains the collectors that ship logs, including their configuration and their own updates.
- Retention and access: Retention and role-based access are set inside the service. Review them on a schedule, because they affect both compliance and spend.
- Alert routing: Monitors and their notification targets stay under your control, and they need review when on-call teams change.
- Exit planning: Export capabilities are limited (browser CSV exports are capped at 100,000 rows), so keep a record of what history you would need if you later move.
Confirm with Sumo Logic which data location, support tiers and contractual terms apply to your account, since renewal and data residency decisions depend on them.
In a mixed model, your organization keeps ownership of the platform and DeployOpen implements, hardens, documents and supports it under a fixed-scope agreement. Ongoing support and upgrades are available as retainers, and the written scope defines which tasks DeployOpen performs and which stay with your staff.
- Upgrades: The scope can name who plans, tests and applies Loki and Grafana upgrades, and how often patch releases are reviewed.
- Backups and restores: The scope can cover backup design for object storage, restore testing and the runbook your team uses during an incident.
- Proxy and access: The scope can include configuration and patching of the authenticating proxy, plus review of the authentication setup in Grafana.
- Alert routing and retention: The scope can define how retention periods are reviewed against your policies and how alert routes are tested.
- Named owners: Even with a partner, your organization must name a platform owner, a security owner and an approver for changes.
Confirm in the written scope which tasks sit with DeployOpen, which sit with your team, the response expectations for each, and how handover happens at the end of the engagement. DeployOpen does not publish a price list, so ask for a quote tied to that scope.
Questions buyers ask before choosing Loki over Sumo Logic
How much effort does a self-hosted Loki take to run?
Effort depends mainly on daily log volume, the deployment mode you pick and how many teams depend on the cluster. Loki documents three modes: monolithic, which is a single binary for up to about 20 GB of logs per day, simple scalable, which is approaching 1 TB per day, and microservices for very large clusters. Running Loki also means operating object storage, a compactor, a log shipper such as Grafana Alloy, Grafana with a MySQL or PostgreSQL database, and an authenticating proxy. Ask your team to size each of these components against your real ingestion profile before comparing the work with Sumo Logic's managed service. The Loki deployment modes documentation is the place to start.
Can our team run Loki without outside help?
A team with Linux, object storage and Kubernetes or VM operations experience can run Loki, but it needs ownership of upgrades, capacity planning and on-call response that Sumo Logic currently carries for you. Note that the simple scalable mode is being deprecated and will be removed with the Loki 4.0 release, so a new build should plan for monolithic or microservices layouts. Skills gaps usually show up in query tuning, label design and compactor behavior. An implementation partner can build and document the stack, but the operating responsibilities stay with your organization unless you sign a retainer for ongoing support.
How long does a migration from Sumo Logic to Loki take?
The timeline is driven by the number of collectors, the volume of log sources, how many searches and dashboards must be translated to LogQL and Grafana, and how much history you need to keep. Forwarding new data can start once the pipeline is in place, but historical data needs its own plan because Sumo Logic's browser CSV exports cap at 100,000 rows per search. Any timeline should come from a written scope agreed before work starts. DeployOpen's engagements are fixed-scope, so the deliverables and schedule are set in writing rather than estimated in advance.
Does Loki replace a SIEM for security monitoring?
No. Loki is a log aggregation and query store, so it does not include the normalization, correlation rules, detection content or case workflows that a SIEM provides. Sumo Logic's Cloud SIEM features would need to be covered by another open-source component, such as Wazuh or a SIEM built on OpenSearch, with Loki acting as one log source or store. Confirm this boundary with your security team before you retire any detection capability, and check the compliance controls you rely on against the tools that will actually perform them.
How is retention set in Loki, and how is it different from Sumo Logic?
In Loki, retention is applied by the compactor and is disabled by default, so logs are kept indefinitely until you set retention_enabled. You can define retention globally, per tenant or per stream selector, and each stream rule must be at least 24 hours. This gives you direct control over how long each application's logs are kept, which also means you own the storage cost that grows with that choice. Set retention in your configuration as a deliberate decision, because an unset value means logs accumulate on object storage with no expiry.
How do we set up multi-tenancy and access control in Loki?
Loki becomes multi-tenant when auth_enabled is true, and each request identifies its tenant with the X-Scope-OrgID header. Loki has no built-in authentication layer, so you must place an authenticating reverse proxy such as nginx, HAProxy, OAuth2 Proxy or Pomerium in front of it to check who is sending or querying logs and which tenant they may use. Grafana's authentication options differ by edition: LDAP, generic OAuth, Entra ID, Okta and similar providers are available in all editions, while SAML, team sync and SCIM provisioning are limited to Grafana Enterprise and Grafana Cloud. Confirm these requirements against your identity provider before design.
What does a DeployOpen engagement need from our side?
A DeployOpen engagement needs a written scope that names your log sources, daily volume estimates, retention requirements, the environments where Loki will run, and the people who will own it afterward. We also need access to your cloud accounts, data centers or air-gapped networks where the stack will be deployed, and to your current Sumo Logic configuration, including collectors, saved searches and dashboards. DeployOpen plans, implements, hardens, documents and supports the platform in your infrastructure, but it does not issue audit reports or certifications. Fixed-scope work is agreed before it starts, and ongoing support is available as a retainer.
How DeployOpen helps you evaluate, implement or migrate Loki
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Loki, that means deciding with you whether Loki fits your log volume, retention and access model, then building it in your environment.
How we scope
- Agree in writing which log sources, daily volumes and retention periods the Loki deployment must cover.
- Confirm which Sumo Logic searches, dashboards and monitors are in scope for translation to LogQL and Grafana.
- Define the deployment mode, object store, tenant layout and authenticating proxy before any build work starts.
How we build
- Install Loki in the deployment mode sized to your daily volume, with object storage and a database-backed Grafana.
- Configure compactor retention rules per tenant or stream selector, so logs are deleted on a schedule you approve.
- Put an authenticating reverse proxy in front of Loki and test tenant isolation through the X-Scope-OrgID header.
How we hand over
- Document the architecture, retention settings, provisioning files and the configuration of each shipper and proxy.
- Provide runbooks for upgrades, backups of object storage and recovery of the compactor and index store.
- Walk your operations and security teams through the handover and the evidence they need for internal reviews.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after the fixed-scope work is complete.
- Plan Loki and Grafana upgrades against their published release cadence and your change windows.
- Ask for a quote based on the written scope, since DeployOpen does not publish a price list.
