Graylog vs ELK: log pipelines, search, and operations

Logs are already collected on a few servers, yet the on-call team keeps repeating the same work: identifying the service, parsing text into usable fields, and checking which team may read which records. The missing piece is more than a search box. It is a log-processing and management workflow that can keep running.

Start with Graylog when collection, parsing, routing, search, and alerting are the central requirements. Favor the Elastic Stack when Elasticsearch is already established, or when search, analytics, and Elastic applications are the foundation for further work. Both require field design, retention, permissions, and capacity planning. Neither “Graylog needs no operations” nor “Elastic is entirely manual” is a useful description.

ELK originally meant Elasticsearch, Logstash, and Kibana; today's Elastic Stack has more ingestion choices. This comparison uses official documentation checked on October 21, 2026, including Graylog 7.2 compatibility. It makes no performance ranking without comparable workload measurements.

Compare the data path before the interface

Elastic's ingest architectures allow Elastic Agent to send directly to Elasticsearch. Logstash is not mandatory in every deployment; introduce additional components for the transformation, buffering, or routing actually needed. A fixed three-component diagram can exaggerate simple deployments while understating the work of a complex pipeline.

Make a payment error searchable

Suppose an application emits JSON containing service, environment, status, and duration. Some durations arrive as strings, and timestamps mix local time zones. A polished search interface will not make those records comparable by itself.

In Graylog, configure an input, parse stable fields, normalize them through Pipelines, and organize payment and gateway logs with Streams. A Stream's destinations and index set determine where data goes. Design storage and access alongside business categories. The current Data Routing documentation connects intake, processing, and destinations; options such as Data Lake have edition boundaries.

In Elastic, an Elastic Agent integration or Logstash can handle ingestion, while an ingest pipeline or Logstash filter parses and enriches records. Mappings ensure durations are numeric and timestamps are dates. Where processing belongs depends on sources, network constraints, and buffering requirements. Elastic transformation and enrichment.

Keep parsing failures visible in either design. Before increasing traffic, send samples with missing fields, invalid timestamps, and oversized content, then inspect their destinations. A lower error count may otherwise mean error logs failed indexing, not that the application recovered.

Use an incident to evaluate search

A payment endpoint starts returning 500 responses after a release. In Graylog, narrow the investigation to the payment Stream, release window, and error fields, then aggregate by version or instance. In Kibana, use Discover to filter the same time range and fields, then use Lens or ES|QL to inspect the distribution. Both paths need consistent service identifiers and field types.

Focus on whether an engineer can move from a summary back to the original record, save useful team queries, and access the necessary data with an ordinary on-call role. An administrator's demonstration does not establish that other teams have the right access. Queries, saved objects, and permission models do not become portable merely because both architectures involve search engines.

Explaining whether the request stalled in a database or an external payment provider requires tracing or other evidence. Log management and APM are related but distinct. Elastic can extend the investigation through appropriately instrumented Observability applications; a Graylog search cannot reconstruct an entire distributed call from a handful of error messages alone.

Graylog 7.2 changes the storage compatibility discussion

Graylog Data Node manages OpenSearch, including versions, extensions, and certificates. MongoDB stores configuration metadata. This reduces some manual administration without eliminating disk capacity, recovery objectives, or backup validation.

The current compatibility matrix lists MongoDB 7.x–8.2.x for Graylog 7.2.x. With self-managed OpenSearch, Open/Enterprise support 1.1.x–3.7.x, while Security supports 2.0.x–3.7.x. OpenSearch 3.x has an important condition: indices created before OpenSearch 2.0 are incompatible and must be addressed before an existing deployment upgrades.

That explains apparent conflicts with older documentation. Graylog 7.1 and earlier have different upper bounds. Do not carry a permanent “no OpenSearch 3.x” warning into 7.2, or use the 7.2 matrix to justify upgrading an older Graylog deployment. Historical elasticsearch_* configuration names also do not establish support for arbitrary current Elasticsearch releases.

Separate free functionality, archiving, and security

Graylog Open provides source-available software under SSPL, with free core collection, search, dashboards, and alerting. It does not have the same entitlements as Enterprise or Security. Check Data Lake, enterprise support, specific archive/restore features, and security detection or investigation against the actual edition and contract. SSPL should not be treated as interchangeable with Apache 2.0; offering a hosted service to others requires particular attention to its terms.

Elastic also separates source licensing, default distributions, and subscription features. In 2024, it added AGPLv3 as an option for free portions of source code, while default Elasticsearch/Kibana distributions remain under ELv2. The earlier 7.11 change is not the whole current story. Elastic licensing FAQ. Check required security controls, connectors, and analysis features against the subscription matrix.

Keeping an archived copy, querying it immediately, and restoring it within an agreed window have different costs. An archive does not imply resource-free recovery or compliance by itself. Make retention, recovery time, permissions, and record integrity separate acceptance criteria.

Cost and the final choice

A self-managed Graylog budget includes the service, MongoDB, Data Node/OpenSearch, backups, and maintenance. A self-managed Elastic Stack budget includes Elasticsearch, Kibana, the ingestion components actually required, and subscriptions. Hosted options reduce some operational work but still incur usage, networking, retention, and migration costs. Shared search-engine concepts do not establish equal performance.

Use the same log sample, retention window, fields, and permission requirements. Exercise an ordinary search, a parsing failure, and backlog recovery. Observe ingestion delay, query latency, disk growth, and staff effort before comparing costs.

Evaluate Graylog first when log operations are the central task and the desired workflow runs from inputs through processing and routing to search. Identify which tasks Open covers and which require a paid edition.

Continue with the Elastic Stack when Elastic data and applications are already valuable engineering assets, or Elasticsearch search and analytics are central requirements. Choose the simplest ingestion architecture that meets those needs rather than installing every component to match the ELK acronym.

The durable choice is the workflow the team can maintain. Field quality, recovery behavior, and access boundaries usually tell you more than the number of charts in an initial demonstration.