Graylog vs OpenSearch: which to choose

Graylog vs OpenSearch: when the Graylog layer is worth its cost

Choose Graylog when your log and SOC team needs a working ingestion, routing and alerting layer on day one and can accept the SSPL, and choose OpenSearch with Security Analytics when your license policy requires Apache-2.0 and your engineers will build the ingestion, dashboards and detections themselves. The question is less about which product indexes logs faster and more about who will own the pipeline after go-live. Graylog Open ships inputs such as syslog, GELF and Beats, routes messages through streams and processing pipelines, and runs event definitions for real-time and historical alerts, with notifications to PagerDuty, Slack and email. Its index model handles rotation by message count, size or time and retention that deletes the oldest indices. Because Graylog Open is licensed under SSPL-1.0, which is not OSI approved, the organization's legal and procurement review must accept that before any design work starts.

OpenSearch is licensed under Apache-2.0 and offers no paid edition in its FAQ, so it suits organizations with a strict open source requirement. OpenSearch Security Analytics matches ingested logs against prepackaged or custom Sigma rules, records findings and correlates them across log types, which lets an engineering team build a SIEM backend without a separate product. The cost is that ingestion, parsing, dashboards and case handling become your work. The OpenSearch Security plugin provides role-based access control, field-level security, audit logs and SAML or OpenID Connect authentication, but you must design and test the roles and the alert workflow. Confirm with OpenSearch and your own environment which detection content and workflow features you need before you commit.

The decision turns on four points. First, license policy: an SSPL requirement can rule Graylog out regardless of fit. Second, which paid Graylog features you need: Enterprise adds data tiering, a correlation engine and 24/7 support, while Graylog Security adds risk scoring, anomaly detection and prebuilt threat content, and both are priced per processed data with minimums that you should confirm against your ingest volume on the Graylog pricing page. Third, operator skills, since a log team can run Graylog while an engineering team may prefer raw OpenSearch. Fourth, the cost of a second layer: Graylog adds server nodes, MongoDB and its own upgrade cycle on top of the search backend. Price the layer against the engineering hours it saves, not against the license alone.

Graylog vs OpenSearch by scenario: which fits your team

This table compares when Graylog on top of OpenSearch fits a team better than running OpenSearch with Security Analytics on its own. Read each row for the condition that makes the choice hold, and check the note on where Graylog Enterprise or Graylog Security changes the answer.

Scenario	Better fit	Why
A SOC that wants a log UI with streams and alerts out of the box	Graylog	Streams, processing pipelines, event definitions and notifications come with Graylog Open. The choice holds if analysts need these without building them. Enterprise or Security adds correlation and prebuilt detection content if those are required.
Platform team with a strict Apache-2.0 policy	OpenSearch with Security Analytics	OpenSearch and its Security Analytics are Apache-2.0, while Graylog Open is SSPL-1.0, which is not OSI approved. Confirm the policy covers the Graylog server before ruling it out, since the search layer alone may satisfy it.
Team that needs archiving, correlation or prebuilt detection content	Graylog Enterprise or Graylog Security, on top of Graylog	Data lake archive restore, data tiering, the correlation engine and Illuminate detection content sit in paid editions, not Graylog Open. Price these against the Graylog pricing page before comparing with a self-built OpenSearch rule set.
Team with existing OpenSearch skills and Sigma-based rules	OpenSearch with Security Analytics	Security Analytics matches logs against prepackaged or custom Sigma rules and correlates findings across log types. Adding Graylog duplicates a layer your team already runs unless analysts specifically need its stream and pipeline model.
Organization that must avoid a second vendor layer	OpenSearch with Security Analytics	Running one open-source search backend keeps the stack to fewer moving parts. Graylog adds a MongoDB tier for configuration and a separate server layer, so confirm whether that footprint is acceptable for your operations team.
Team that must keep an OSI-approved license across the whole stack	OpenSearch with Security Analytics	Every component in the OpenSearch project is Apache-2.0, so no license exception is needed. Graylog Enterprise and Graylog Security remain under commercial terms as well, so the paid tier does not resolve the license question.
Team that wants Data Node to handle cluster certificates and versions	Graylog with Data Node	Graylog recommends Data Node as its search backend, and it manages OpenSearch for you. Hardening and version planning still fall to your team, so confirm how this fits your change control.
Team that expects heavy ingest and wants clear sizing rules	Depends on your ingest profile	Graylog documents a storage sizing rule of daily ingest times retention days times 120 percent, plus a message journal of 3 to 5 times daily ingest. Run the same sizing for a bare OpenSearch cluster, since the data volume is equal either way.

How Graylog and OpenSearch are built and deployed

Graylog is a layered product: its own server nodes and MongoDB sit on top of a search backend that stores the logs. OpenSearch on its own is the backend, with Security Analytics added as a SIEM layer, so the choice is really about how many layers your team wants to run and patch.

Graylog server nodes and MongoDB

Graylog server nodes handle inputs, streams, processing pipelines, alerting and the web interface, while MongoDB holds configuration and metadata. Graylog 7.2 supports MongoDB 7.x up to 8.2.x, so confirm that range against your MongoDB packaging before you build. Each layer you add is another service to back up, patch and monitor, and the multi-node guide expects a MongoDB replica set alongside the Graylog nodes.

Graylog Data Node as the search backend

Graylog documents Data Node as its recommended search backend. It installs and manages OpenSearch for the Graylog deployment, so your team does not run a separate OpenSearch cluster for logs. Confirm that Data Node meets your needs for certificate handling, cluster membership and version control before you choose it over a self-managed cluster your own team operates.

Self-managed OpenSearch under Graylog

Graylog 7.2 accepts self-managed OpenSearch from 1.1.x up to 3.7.x, while OpenSearch 3.9.0 is already the current release. Confirm the exact version pairing before you build, because a cluster on 3.8 or 3.9 falls outside the documented range. Graylog Security needs OpenSearch 2.0 or later, and use of OpenSearch 1.x is deprecated since Graylog 7.0 and will be removed in Graylog 8.0. Your team then owns hardening, upgrades and cluster sizing.

OpenSearch alone with Security Analytics

Without Graylog, OpenSearch Security Analytics matches ingested logs against prepackaged or custom Sigma rules, records findings and correlates them across log types. This removes the Graylog server and MongoDB layers, but your team builds the ingest, routing and alert workflow that Graylog provides. Check which inputs, retention controls and notification paths you need before accepting that trade-off.

Operating consequences of each layer

Graylog plus OpenSearch means two version lines to track, with Graylog releases and OpenSearch maintenance windows that may not line up. OpenSearch alone means one version line but more custom work for pipelines and alerts. Ask your vendor or integrator to write down who patches each layer, how upgrades are tested against the version matrix, and how the cluster is backed up before you commit.

Graylog vs OpenSearch features: what each provides on its own

This table compares what Graylog and OpenSearch each provide without add-ons, row by row across licensing, ingestion, alerting, detection content, archiving and access control. Read each row as a question to answer for your own team: where a capability is missing from OpenSearch, you will have to build it or buy a layer that provides it, and where Graylog's paid editions are the source, the cost is recurring. Entries marked for confirmation depend on current vendor documentation and should be checked before you commit.

Capability	Graylog	OpenSearch
License	Graylog Open under SSPL-1.0, which is not OSI approved	All OpenSearch project software under Apache-2.0
Paid editions	Graylog Enterprise and Graylog Security are paid, licensed on processed data	No paid edition described in the OpenSearch FAQ
Log inputs	Built-in inputs such as syslog, GELF and Beats	No ingestion product included; you build pipelines with tools such as Logstash, Data Prepper or Beats
Streams and processing pipelines	Streams and processing pipelines route and transform messages in the product	Not provided as a product feature; you build routing and transformation outside or on top of the cluster
Event alerting	Event definitions for real-time and historical monitoring, with notifications to PagerDuty, Slack and email	Alerting is available; confirm the supported notification channels and monitor types in the OpenSearch alerting docs
Sigma detection and correlation	Correlation engine is a paid Enterprise feature	Security Analytics matches logs against prepackaged or custom Sigma rules and correlates findings across log types
Archiving and tiering	Data lake with archive restore and data tiering in Graylog Enterprise	Storage tiering and archiving depend on your cluster design and tooling; confirm current options in the OpenSearch docs
Prebuilt detection content	Illuminate prebuilt detection content in Graylog Security	Security Analytics ships prepackaged Sigma rules; confirm coverage against your log sources
Identity and single sign-on	Confirm supported authentication backends in Graylog's user authentication documentation	Security plugin supports SAML, OpenID Connect, Active Directory and LDAP, Kerberos and JSON Web Token
RBAC, field-level security and audit logs	Confirm role and audit options for your edition with Graylog	Security plugin provides role-based access control, document and field-level security, field masking, user impersonation, audit logs and TLS

What Graylog and OpenSearch license terms and paid editions cover

Graylog Open is the free edition of the Graylog server. Since Graylog 4.0 in 2020, it has been licensed under the Server Side Public License version 1 (SSPL-1.0), which replaced the GPL v3 used by earlier releases. The SSPL is not approved by the Open Source Initiative, so Graylog Open should not be described as open source in procurement or policy documents, even though the source is published.

Use terms: The SSPL has conditions for offering the software as a service to third parties. Running Graylog Open for your own staff inside your own infrastructure is a different situation from offering it to customers, so have counsel confirm the terms for your specific use.
Pricing: The Graylog pricing page lists Graylog Open as free, with no volume limits and community support.
Feature boundary: Inputs, streams, processing pipelines, search, dashboards, index rotation and retention, and event-based alerts are part of the open edition.
Missing from Open: Index archiving, correlation, reporting and prebuilt Illuminate detection content sit in the paid editions.
Support: Community support is the only support route listed for Open, so budget for internal or partner operations work.

Confirm the current license text in the LICENSE file and the edition matrix before you set policy.

What drives the running cost of each stack

Both stacks store logs in OpenSearch, so the storage bill looks similar at first. The difference lies in what sits on top: Graylog adds MongoDB, a server tier and a licensed edition, while a bare OpenSearch cluster adds building effort and your own support model. Use these cards to build the cost model before you request quotes.

Infrastructure footprint

Graylog needs MongoDB for configuration and metadata in addition to a search backend, so you run two data stores and a Graylog server tier. Sizing for log storage uses daily ingest times retention days times 120 percent, and the message journal is recommended at 3 to 5 times daily ingest on SSDs. Ask the implementer to show both calculations for your ingest rate and retention, and to list every node, disk and load balancer in the quote.

License cost

OpenSearch carries no license fee under Apache-2.0, and the OpenSearch FAQ describes no paid edition. Graylog Open is free, but Graylog Enterprise starts at 15,000 US dollars per year and Graylog Security at 18,000 US dollars per year, per the Graylog pricing page, each with a minimum of 10 GB per day or 100 Graylog Compute Units. Confirm which Graylog features your team needs, since archive, correlation and prebuilt detection content sit in the paid tiers.

Build and operating skills

On bare OpenSearch, your team builds ingestion, dashboards, alert logic and access rules with OpenSearch Dashboards and Security Analytics, which means more custom engineering and ongoing ownership of that work. Graylog supplies inputs, streams, processing pipelines and event definitions as its own model, which shortens build time but requires staff to learn that model. Ask for a scoped list of what will be built, who will maintain it, and what knowledge transfer is included.

Support model and hours

Graylog Enterprise includes 24/7 support, and Graylog Open is supported by its community. OpenSearch support comes from the OpenSearch project community or from vendors that sell it, and DeployOpen offers retainers for ongoing support, upgrades and continuous testing on a fixed-scope basis. Confirm the support hours, response commitments and escalation path in writing, because these differ between a vendor contract and a retainer.

Upgrade cadence and pairing

OpenSearch targets a new minor version about every eight weeks, and each version stays in maintenance until the next major enters maintenance or one year passes, whichever is longer. Graylog 7.2 supports OpenSearch from 1.1.x up to 3.7.x, and Graylog recommends Data Node, so an OpenSearch upgrade may also require a Graylog upgrade. Ask who owns each upgrade, how compatibility is tested before rollout, and how long each version receives patches.

How identity and access integration differs on each stack

On OpenSearch alone, login and role separation sit in one security layer, and that layer is the one your access reviews will cover. The OpenSearch Security plugin supports SAML, OpenID Connect, Active Directory and LDAP, Kerberos and JSON Web Token authentication backends. Analyst access is then shaped by role-based access control, document-level and field-level security, field masking, user impersonation and audit logs, with TLS for node and client traffic. In practice, map each analyst group to a role that limits index patterns and masks sensitive fields, then test that a tier-one role cannot read the indices reserved for incident responders. Confirm the exact role mapping behavior for your chosen backend in the OpenSearch security documentation.

Graylog adds its own user, role and permission model on top of the search backend, so the answer to "who can log in and what can they see" depends on the Graylog version you deploy. Check Graylog's user authentication documentation for the LDAP, OIDC and role mapping options in your release, and confirm which of them are available in Graylog Open and which need a paid edition. Also confirm how the Graylog server authenticates to OpenSearch or Graylog Data Node, which service accounts it uses, and whether that connection is protected with TLS. Do not assume that SSO configured on the Graylog front end also governs direct access to the indices. Test both paths before you sign off the design.

The practical consequence is a second access layer to govern. Analysts who sign in through Graylog receive permissions over streams, searches and dashboards, while anyone who reaches OpenSearch directly is bound only by backend roles. Your access review should therefore export user lists, role assignments and group mappings from both systems, then reconcile them against your joint identity source. Remove direct OpenSearch access for analysts where Graylog is the intended interface, and record who holds administrator rights on each layer. Set the review cadence against your own control framework, because the sources do not prescribe one. Mismatched entries between the two layers are the most common gap an auditor will find.

Moving between Graylog and OpenSearch later

The sequence below moves log ingest, search and detection content from one stack to the other while keeping the old system readable for the retention period. It produces a validated cutover and a documented archive position, not a silent switch.

Inventory what the current stack actually does
Your platform or SOC engineers list every input, stream, processing pipeline, event definition, dashboard, notification channel, index set and retention rule, plus every user role and log source that depends on them. Record which items live in Graylog configuration (MongoDB) and which live in the search backend (indexed data). The output is a written inventory that separates what must be rebuilt from what is only data. Confirm the export options for streams and pipelines with Graylog's documentation before assuming any of them can be carried over automatically.
Confirm what transfers and what does not
Indexed log data is tied to the search backend that stores it. OpenSearch is wire-compatible with Elasticsearch 7.10 and can use indices from Elasticsearch 6.0 through 7.10 with rolling upgrades, but that compatibility applies to the search backend, not to Graylog's configuration. Graylog streams, pipelines, event definitions and dashboards are not indices and should be treated as a rebuild on the target. Ask the vendor and the OpenSearch documentation to confirm the exact migration path for your versions, and record the answer in the inventory. The output is a signed-off transfer list that names each item as data, configuration or rebuild.
Stand up the target and ingest in parallel
Build the target stack (Graylog on OpenSearch or Data Node, or OpenSearch with Security Analytics) alongside the existing one, with the same TLS, identity and role model. Point a subset of log sources at both systems so each event reaches old and new in parallel. Use the Graylog compatibility matrix to confirm the supported OpenSearch range before deploying. The output is a running target that receives the same events as the source, verified by comparing message counts for a sample window.
Rebuild streams, pipelines and detection rules
Recreate Graylog streams, processing pipelines and event definitions on the target, or translate detections into OpenSearch Security Analytics rules. Sigma rules used by Security Analytics can be carried across where the rule content matches your log fields, but field mappings must be checked one by one. Note any rule that depends on a paid Graylog edition feature, such as correlation or prebuilt content, because the target may not provide it. The output is a rule register that maps each source detection to its new home, with a status for each entry.
Validate detections against known events
Replay test events or known attack traces through both systems and compare which alerts fire, when they fire and what fields they carry. Recreate dashboards and notification routes to PagerDuty, Slack or email, and confirm each one reaches the right responder. Check role-based access so analysts see the same data scope on both sides. The output is a validation record listing each detection, its result on old and new, and each gap accepted or fixed before cutover.
Cut over sources and retire the old path
Move each log source from the old stack to the new one in an agreed order, keeping the old path in place until the new one is confirmed. Remove duplicate forwarding only after the validation record is signed off by the detection owner and the SOC lead. The output is a dated cutover log showing each source, its switch time and the person who approved it, along with a rollback path for each source.
Handle archives and historical search
Decide how data indexed on the old backend stays searchable for the retention period your policy requires. Options include keeping the old cluster read-only for historical queries, exporting data to a format your compliance team accepts, or restoring old indices into the target where version compatibility allows. Confirm with your auditors or compliance lead which records must remain retrievable and for how long, and confirm the restore path with Graylog and the OpenSearch documentation. The output is a documented archive position stating where each data set lives, who can query it and how it is retrieved.

Where Graylog and OpenSearch implementations usually run long

The Graylog build runs longest on the layers under the product. For medium to large deployments, the Graylog multi-node guide recommends three Graylog and MongoDB nodes with MongoDB as a replica set, three Data Nodes on their own cluster, and a load balancer in front of the Graylog servers, with is_leader set to false on follower nodes. Each of those pieces needs certificates, network rules, replica set health checks and failover tests before anyone sends logs. Ask any provider to scope sizing explicitly: the Graylog system architecture page advises log storage of daily ingest times retention days times 120 percent, plus a message journal of 3 to 5 times daily ingest on SSDs. Confirm how the provider will measure real ingest, since estimates made before onboarding often move once sources are connected.

The OpenSearch build runs longest on cluster design and security configuration. A team that chooses OpenSearch alone must decide node roles, shard layout and index lifecycle, then configure the Security plugin for SAML or OpenID Connect, role mapping, document and field-level security and audit logs. Security Analytics adds its own work: Sigma rules must be loaded, tuned against your own log sources to reduce false positives, and correlated across log types, and dashboards must be built from scratch because Graylog's streams, pipelines and event definitions have no direct counterpart. Ask the provider who owns rule tuning after handover and how many rule changes are included in scope.

Across both builds, the expensive problems are the same. Version pairing is the first: Graylog 7.2 supports OpenSearch from 1.1.x up to 3.7.x, and OpenSearch 1.x use is deprecated in Graylog 7.0 and removed in Graylog 8.0, so the search backend version must match the Graylog release you plan to run. Retention and archive design, identity mapping from directory groups to roles, and hardening left to the client are the other common sources of overrun. Ask the provider to put each of these in the written scope with a named owner, and to state which items the client must supply, such as directory access, certificates and sample log sources.

Graylog vs OpenSearch questions buyers ask before hiring help

Is Graylog Open or OpenSearch alone enough for a small SOC?

It depends on whether you need a log workflow or only a search backend. OpenSearch with Security Analytics can serve as a SIEM backend, matching ingested logs against prepackaged or custom Sigma rules and correlating findings across log types, so a small team can start there with no separate product. Graylog Open adds inputs such as syslog, GELF and Beats, streams, processing pipelines, dashboards and event-definition alerts sent to PagerDuty, Slack or email. Archiving, correlation, reporting and prebuilt Illuminate detection content sit in paid Graylog Enterprise or Graylog Security editions, so confirm which of those features your analysts need before choosing.

What does the SSPL mean for internal use of Graylog Open?

The Server Side Public License version 1 (SSPL-1.0) is not OSI approved, so Graylog Open is source available rather than open source. Your organization's internal use is a question about the license text and how you deploy it, including whether you offer Graylog as a service to others. Confirm the specific obligations with your legal counsel before you commit, and review the Graylog2/graylog2-server LICENSE file that Graylog publishes. OpenSearch, by contrast, is licensed under Apache-2.0, which is an OSI-approved license.

How much do Graylog Enterprise and Graylog Security cost?

The Graylog pricing page lists Graylog Enterprise from 15,000 US dollars per year and Graylog Security from 18,000 US dollars per year. Both carry a minimum of 10 GB per day or 100 Graylog Compute Units, and licensing is on processed data with no per-user or per-device fees. Price drivers are the ingest volume you license, the edition you need and the support level, so ask Graylog for a written quote that states the volume basis and what is included. Graylog Open itself is free with no volume limits, but you still pay for the hosting, storage, staff time and any outside help you buy.

Can our own team run Graylog or OpenSearch without outside help?

A team with Linux, certificate management and search cluster experience can run either stack, but the work is not small. Graylog needs server nodes, MongoDB for configuration, and either Graylog Data Node or self-managed OpenSearch for storage, and Graylog recommends Data Node as the search backend. OpenSearch needs its own cluster design, security configuration, upgrades on its release cadence and monitoring. Assess your staff on those skills and on the on-call time you can commit before deciding whether to hire implementation or ongoing support.

What does the work need from our side?

Expect to provide infrastructure access, a named technical owner, and staff time for requirements, log source inventory and testing. Infrastructure access covers the cloud accounts, data centers or air-gapped networks where the platform will run. Change windows matter because cluster upgrades, MongoDB changes and index migrations can affect live log ingestion. DeployOpen works under a fixed scope with deliverables and timelines agreed in writing before work starts, so the client-side commitments should be written into that scope.

Can Graylog 7.2 run on the OpenSearch version we plan to use?

Check the compatibility matrix for your exact versions before you choose. According to the Graylog compatibility matrix, Graylog 7.0 to 7.2 support OpenSearch from 1.1.x up to 3.7.x, and Graylog Security needs OpenSearch 2.0 or later. OpenSearch 3.9.0 was released on September 29, 2026, which is newer than the 3.7.x upper bound listed for Graylog 7.2, so a current OpenSearch 3.9.0 deployment would fall outside that listed range. Graylog also documents Data Node as the recommended backend and deprecates OpenSearch 1.x from Graylog 7.0, so confirm the supported pairing with Graylog before you buy hardware.

How long does an implementation take?

The timeline depends on the written scope, not on a fixed duration. The main drivers are the number and type of log sources, whether you need a single node or the multi-node layout that Graylog recommends for medium to large deployments, the storage sizing, the detection content you configure, and how many environments you must harden and test. Graylog's system architecture guidance on sizing storage and the message journal can help you estimate hardware early. Ask for a fixed-scope proposal with milestones and dependencies stated, rather than a single calendar estimate.

How hard is it to move from one stack to the other later?

Moving is possible but it is a migration project, not a configuration change. Graylog stores log data in its search backend and configuration in MongoDB, so a move between Graylog and a plain OpenSearch deployment involves rebuilding streams, pipelines, event definitions and dashboards, and deciding what happens to historical indices. OpenSearch is wire-compatible with Elasticsearch 7.10 and supports rolling upgrades from supported earlier versions, which helps within the OpenSearch line. Plan for the rebuild cost, retention of historical data and testing of alerts before you commit to either path.

How DeployOpen helps choose, implement or migrate log platforms

DeployOpen is a Chainscore Labs company that plans, implements, hardens and supports self-hosted open-source platforms inside your own infrastructure. For Graylog vs OpenSearch, we help you test which layer your log and security use cases actually need before you commit to a build.

How we scope

We confirm which log sources, retention periods and detection use cases the platform must cover before choosing a stack.
We document whether Graylog streams, pipelines and alerting, or OpenSearch Security Analytics, fits your team's operating model.
Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before any work starts.

How we build

We size the OpenSearch or Graylog Data Node cluster against your daily ingest, retention and index rotation settings.
We configure inputs, pipelines or Sigma-based detections, then test alert routing end to end with your own sample logs.
We set up authentication, role-based access and TLS according to the requirements in your written scope.

How we hand over

You receive configuration documentation, runbooks for index rotation and retention, and a record of every deviation from defaults.
We walk your operators through upgrade paths, including the license and maintenance windows that apply to your chosen versions.
We prepare evidence of configuration and access controls for your own compliance assessors, who issue any audit opinion.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainers can cover version upgrades when Graylog or OpenSearch releases move a line into maintenance or end of life.
Ask any provider, including us, to confirm in writing which edition features, support hours and upgrade tasks are included.

Graylog vs OpenSearch