OpenSearch vs Elasticsearch: when each fits
If your team needs Apache-2.0 terms and Security Analytics without a subscription, OpenSearch fits. If you need Elastic's own detection engine, machine learning anomaly detection or endpoint prevention and you accept Elastic's licensing and paid tiers, Elasticsearch fits. Start by checking which of those two requirements is fixed, because it narrows the rest of the decision. Also check whether a product above the engine has already made the choice. Wazuh's indexer is an open source fork of OpenSearch, and Graylog 7.2 indexes log data in self-managed OpenSearch 1.1.x to 3.7.x or Graylog Data Node. Security Onion bundles Elasticsearch, so a team adopting one of those products may not be choosing a search engine at all.
The decision turns on four things. First, license obligations: OpenSearch is Apache-2.0 and derived from Elasticsearch 7.10.2, while Elasticsearch source is available under Elastic License 2.0, SSPL 1.0 or AGPLv3 at your option, so have counsel confirm which terms apply to your deployment and whether you plan to offer the stack to others. Second, which paid features your SOC needs. Elastic places the detection engine, machine learning anomaly detection and case management under Platinum, which Elastic no longer sells to new customers, and endpoint malware and ransomware prevention, host isolation and SAML or OpenID Connect single sign-on under Enterprise. Confirm current availability on Elastic's subscriptions page before you plan around any tier. Third, the skills and estate you already run. Third-party Elastic clients, dashboards and runbooks may need rework on OpenSearch, so inventory them.
The fourth factor is the cost of moving later. Switching engines after you have built detections, dashboards and index lifecycle policies means re-testing those assets, re-validating ingest pipelines and planning a data migration or reindex window. Ask the vendor or your implementation partner for a written list of the features and APIs your current configuration depends on, then test them on the target engine before committing. Also confirm which release line you will run: OpenSearch 3.9.0 and the 2.19 maintenance line are current on OpenSearch's releases page, and Elastic 9.5.5, 9.4.8 and 8.19.23 are the Elasticsearch lines listed on its GitHub releases page. Make the choice against the version you will support for the life of the platform.
OpenSearch vs Elasticsearch by scenario
This table maps common situations to the engine that fits better and the condition that makes it so. Read each row against your own license obligations, subscription needs and existing estate, and confirm license interpretation with counsel and feature availability with each vendor before deciding.
| Scenario | Better fit | Condition that makes it hold |
|---|---|---|
| Internal redistribution where Apache-2.0 terms are required | OpenSearch | Your legal team needs permissive terms for code you ship or redistribute, and counsel confirms Apache-2.0 suits the distribution model. |
| SOC that needs Elastic's paid detection engine and machine learning | Elasticsearch (Elastic subscription) | Detection engine, machine learning anomaly detection and case management are required, and you accept the subscription tier that includes them. Confirm current tier names with Elastic. |
| Existing Elastic 7.x or 8.x estate with Elastic-only tooling | Elasticsearch | Your indices, pipelines and integrations already depend on Elastic releases, and moving to OpenSearch would be a migration project rather than an upgrade. |
| Product that embeds a SIEM search backend and must ship it | OpenSearch | You redistribute the backend inside your product and need license terms your counsel accepts. Security Analytics is available in OpenSearch without a separate product. |
| Team that runs Graylog or Wazuh on top of the engine | OpenSearch | Graylog 7.2 and Wazuh's indexer both use OpenSearch-compatible backends, so check the supported version range before choosing. Graylog also supports its own Data Node. |
| Company with a strict OSI-approved license policy | OpenSearch | Your policy requires OSI-approved licenses. ELv2 is not OSI approved, so confirm the license of any Elastic component you would use. |
| No subscription budget and no paid features required | OpenSearch | Core search and Security Analytics meet your needs and you can operate upgrades and support internally or through a services partner. |
How each engine is built and what that means for operations
OpenSearch and Elasticsearch share a common ancestry, but they now follow different licenses, release lines and feature paths. The cards below cover what each engine is built from, how it is licensed, which lines are maintained, and what running both in one estate means for upgrades and version tracking.
OpenSearch under Apache-2.0
OpenSearch is licensed under Apache-2.0 and derived from Elasticsearch 7.10.2. Its dashboard layer, OpenSearch Dashboards, is derived from Kibana 7.10.2. For most teams this means the core engine and UI can be deployed, modified and redistributed under a permissive license. Check whether your legal team reads Apache-2.0 as acceptable for your product and hosting model, and confirm which features in your plan come from the OpenSearch project rather than a vendor add-on.
Elastic under ELv2 by default
Elasticsearch and Kibana are available under three licenses: the Elastic License 2.0 as the default distribution, SSPL 1.0, and AGPLv3. The ELv2 default restricts offering the software as a managed service. Before choosing a distribution, confirm with counsel which license applies to the exact build you deploy, since the choice changes obligations for internal use, modification and any hosted offering you run for others.
Current release lines on each side
OpenSearch 3.9.0 is the current release, and the 2.19 line still received a 2.19.6 maintenance release. On the Elastic side, 9.5.5 and 9.4.8 are the current lines, and 8.19.23 is still maintained. Compare these against your own patch policy. A platform team running an older line needs to know which lines receive fixes and plan the next major move before the one it runs stops receiving them.
Wazuh indexer as an OpenSearch fork
The Wazuh indexer is an open source fork of OpenSearch. Teams that adopt Wazuh for endpoint and SIEM coverage therefore inherit a second OpenSearch lineage that is maintained by the Wazuh project, not by the OpenSearch project directly. Ask which upstream OpenSearch version a given Wazuh release is built on, and how the Wazuh team handles security fixes that land upstream first.
Two engines, two upgrade cycles
Running OpenSearch for logs and Elasticsearch for another tool creates two version histories, two security advisory streams and two sets of plugin compatibility checks. Upgrade plans must track both, and index formats and client libraries may diverge over time. Document which engine each index family depends on, assign an owner for each upgrade track, and test snapshot restore on both before any cutover. Confirm each vendor's support window before committing.
What each license allows and what is paid for
OpenSearch is distributed under Apache-2.0, a permissive license. In plain terms, you can run, modify and redistribute it inside your own environment, including for commercial purposes, as long as you keep copyright and license notices, include a copy of the license with any redistribution, mark the files you changed, and carry forward the attribution text in the NOTICE file. The license grants no trademark rights and disclaims warranties, so any support commitment or indemnity comes from the party you contract with, not from the license itself. Security Analytics is part of the open distribution and is documented as a SIEM backend.
- Attribution duties: Keep license headers and the NOTICE file when you repackage builds, including internal container images and golden AMIs.
- Modification freedom: Apache-2.0 does not require you to publish changes to the engine or Dashboards, but you must mark what you changed.
- Security Analytics: Ingested logs are matched against prepackaged or custom Sigma rules, findings are recorded, and events are correlated across log types.
- Support options: The supplied facts name no OpenSearch subscription tier, so ask the OpenSearch project and any commercial provider which support levels exist, what they cover and how they are priced.
- Feature parity: Confirm in your own test environment that the Security Analytics rules, alerting and access controls you plan to use are present in the release line you intend to deploy.
Confirm with your counsel how your internal packaging and redistribution map to these duties before you ship a modified build.
Elastic publishes Elasticsearch and Kibana source code under three license options: the Elastic License 2.0 as the default distribution, SSPL 1.0 and AGPLv3. AGPLv3 was added in 2024, before the 8.16 release, so a team that assessed only ELv2 or SSPL earlier should revisit its position. Several capabilities sit behind paid subscription tiers, so the tier you hold, not only the license you choose, decides which features you can use.
- Elastic License 2.0: The default distribution. It is not OSI approved and restricts offering the software as a managed service, so any hosted offering for other parties needs review.
- SSPL 1.0: A copyleft option that is also not OSI approved, with obligations that counsel should read in full before selection.
- AGPLv3: Added in 2024, before 8.16. It is OSI approved and copyleft, and its network clause can require source availability to users who interact with a modified version over a network.
- Platinum: Covers the detection engine, machine learning anomaly detection and case management. Elastic no longer sells Platinum to new customers, so confirm what existing agreements include and what renewal paths exist.
- Enterprise: Lists endpoint malware and ransomware prevention, host isolation, and SAML or OpenID Connect single sign-on. Budget only after confirming current inclusions and pricing in writing.
Check the Elastic subscriptions page and your counsel before deciding, because tier names, inclusions and availability change.
OpenSearch vs Elasticsearch capability comparison
This table compares OpenSearch and Elasticsearch on license, release lines, detection content and the features Elastic places in paid tiers. Where the researched facts do not establish a capability, the cell says to confirm it with the vendor before you rely on it. The main takeaway is that OpenSearch's Apache-2.0 base suits teams that will build or source their own detection content, while Elastic's paid tiers suit teams that want vendor-packaged machine learning, endpoint and single sign-on features.
| Capability | OpenSearch | Elasticsearch |
|---|---|---|
| License and derivation | Apache-2.0. Derived from Elasticsearch 7.10.2. Favors teams that need permissive terms. | Elastic License 2.0 by default, with SSPL 1.0 and AGPLv3 options. Confirm which terms fit your use. |
| Current release lines | 3.9.0 (September 29, 2026). The 2.19 line received 2.19.6 on July 6, 2026. | 9.5.5 and 9.4.8 (October 6, 2026). The 8.19 line still receives 8.19.23. |
| Security Analytics or equivalent detection content | Security Analytics matches logs against Sigma rules, records findings and correlates across log types. | Detection engine is listed under Platinum, which Elastic no longer sells to new customers. Confirm current packaging. |
| Machine learning anomaly detection | Not established by the supplied facts. Confirm with the vendor before relying on it. | Listed under Platinum, which Elastic no longer sells to new customers. Confirm the tier that applies to you. |
| Case management | Not established by the supplied facts. Confirm with the vendor. | Listed under Platinum, which Elastic no longer sells to new customers. Confirm availability for new subscriptions. |
| Endpoint prevention and host isolation | Not established by the supplied facts. Confirm with the vendor and plan for a separate endpoint control if needed. | Endpoint malware and ransomware prevention and host isolation are listed under Enterprise. |
| SAML or OIDC single sign-on | Confirm with the vendor which SSO methods the Apache-2.0 distribution includes. | SAML and OpenID Connect single sign-on are listed under Enterprise. |
| Paid tier location | No paid OpenSearch tier is named in the supplied facts. Confirm any commercial support or distribution with the vendor. | Platinum (no longer sold to new customers) and Enterprise on the self-managed subscription page. |
| Vendor-supported SIEM content | Prepackaged Sigma rules ship with Security Analytics. Confirm the support terms for content updates. | Detection content is tied to subscription tiers. Confirm which rules you receive at your tier. |
What drives running cost on each platform
Running cost for OpenSearch and Elasticsearch splits into infrastructure, licensing, people, upgrades and support. The weight of each component depends on the SIEM product built on top, so a cost comparison has to start from the workload and the team that will operate it.
Infrastructure and hardware sizing
Storage, search nodes and compute scale with the log volume, retention period and the product on top. Security Onion lists bare minimum hardware of 4 CPU cores, 24GB RAM and 200GB storage for a standalone install and suggests 32GB of RAM or more when monitoring even a small amount of network traffic. That shows how a consuming product changes sizing, so ask each vendor and integrator for a sizing estimate based on your own event rate, retention and replica settings. Cloud or data center costs recur every month, and they are the same whichever engine you choose.
Licensing and subscriptions
OpenSearch carries no supplied subscription fee because it is Apache-2.0 software, so its cost is the infrastructure and the people who run it. Elasticsearch self-managed features such as machine learning, case management and endpoint prevention sit in paid Elastic subscription tiers, which recur on a term basis. Ask Elastic for a written quote that names each feature you need, the tier it falls under, and whether the price renews annually. Confirm which tiers are still sold to new customers before you model a multi-year cost.
Skills and staffing
Teams that already operate Elasticsearch and Kibana can usually transfer that knowledge to OpenSearch, because OpenSearch was derived from Elasticsearch 7.10.2. Operational differences in security plugins, Security Analytics content and upgrade paths still need training time. Estimate the engineering hours for cluster tuning, index lifecycle management, and alert tuning on each platform. Ask your integrator to name the engineers who will run the environment after handover and what documentation they will leave.
Upgrades across two release lines
Each engine has active release lines that need planning. OpenSearch 3.9.0 is current and the 2.19 line still received 2.19.6, while Elastic 9.5.5 and 9.4.8 are current with 8.19.23 still maintained. Running two supported lines at once means a second upgrade track for security patches and plugin compatibility. Budget test environments, change windows and regression testing for each line you run, and confirm the end-of-support date for any version you deploy.
Support and services options
Support can come from the vendor, from an integrator or from your own staff, and each option carries a different recurring cost. Elastic support is part of its paid subscriptions, while OpenSearch support depends on the provider you choose. DeployOpen plans, implements, hardens, backs up, upgrades and supports self-hosted platforms in your infrastructure, mostly under fixed-scope agreements, with ongoing support and upgrades available as retainers. Request a written scope listing deliverables, response expectations and what is excluded before you compare quotes.
Moving from Elasticsearch to OpenSearch, or back, step by step
This sequence moves a log and detection stack between Elasticsearch and OpenSearch without losing alert coverage, and ends with one cluster that the team can prove is doing the work the old one did.
Confirm license and feature dependencies
Start by listing every Elastic component the stack depends on and the license terms that apply to each. Elastic's source code is available under the Elastic License 2.0, SSPL 1.0 and AGPLv3, and OpenSearch is Apache-2.0, so the license review should name the distribution the team runs today and the one it plans to run next. Legal and procurement should sign off on that record, and the team should confirm with Elastic and OpenSearch which features they can run on the target. The output is a written license and dependency register that names each paid or proprietary feature in use.
Inventory Elastic features in use
Walk the current cluster and record every feature the SOC relies on: subscription-tier features such as the detection engine, machine learning anomaly detection, case management, endpoint prevention, host isolation and single sign-on; Kibana saved objects including dashboards, saved searches and data views; alerting rules and connectors; and security rules. Each item gets an owner and a note on whether it is used in production. The output is a feature inventory that separates features the team must keep from features it can drop, so the rebuild scope is known before any build starts.
Inventory mappings, pipelines, templates and retention
Export index mappings, ingest pipelines, index templates, index lifecycle or retention policies, and field naming conventions. Compare them against the target engine's documented behavior, because a field type or pipeline processor that works in one engine may need a change in the other. The team should confirm each pipeline processor and template setting against the target version's documentation. The output is a per-index list of what moves unchanged, what needs a change and what has no equivalent yet.
Choose the target version line
Pick a specific release line on the target side and record the compatibility constraints that come with it. Current lines documented in the supplied facts include Elasticsearch 9.5.5 and 9.4.8, with 8.19.23 still maintained, and OpenSearch 3.9.0, with the 2.19 line still receiving maintenance. Readers should confirm which lines their chosen tooling, agents and integrations support, and whether a direct upgrade path exists from their current version. The output is a signed version decision with the upgrade or migration path written down.
Rebuild dashboards and detection content in target tooling
Recreate Kibana-specific objects in OpenSearch Dashboards or the reverse, and rebuild paid-feature workflows on the target side. Security Analytics rules on OpenSearch use Sigma rules, so detection logic written as Elastic detection rules must be translated and tested rather than copied. Expect workflows such as case management, endpoint response and single sign-on to need a fresh design, and confirm which of these the target stack offers under its license. The output is a rebuilt set of dashboards and rules, each tagged with its source object so reviewers can trace it back.
Run both stacks in parallel and validate alert parity
Feed the same log sources to the old and new clusters for a fixed observation window agreed in writing before the test starts. Compare alert volumes, rule hits, false positive reviews and dashboard results for the same events. Any alert that fires on one side but not the other needs a documented cause and a fix or an accepted gap. The output is a parity report signed by the SOC lead, listing every known difference and its disposition.
Migrate data and cut over
Move historical data through a supported path, such as a reindex or a snapshot restore where the two versions allow it. The team should confirm the snapshot and reindex support for its exact source and target versions, and test a restore on a copy before relying on it. Once historical data and parity checks pass, switch log forwarders to the new cluster, keep the old cluster read-only for a rollback window, and record the cutover time. The output is a cutover record with verified document counts and a tested rollback plan.
Retire the old cluster and document the result
After the rollback window closes and the team has accepted the parity report, take a final snapshot for retention, then shut down and decommission the old cluster. Update runbooks, access controls, backup jobs and the license register so they describe only the surviving stack. The output is a decommission record and an updated architecture document that the next audit or review can use as evidence.
Where self-hosted SIEM projects usually run long
The longest phases of a self-hosted SIEM project are rarely the installation. Sizing and storage architecture, detection content migration and parallel-run validation are where schedules slip, and they apply to both OpenSearch and Elasticsearch. Start by fixing the sizing inputs in writing: daily ingest volume by source, the hot, warm and cold retention windows, replica count and the number of nodes each tier needs. Confirm these against the vendor's current sizing guidance for your chosen release line, because index shard counts and heap settings that work for a lab often fail under production ingest. Cluster topology decisions (dedicated master, data and ingest roles, or a combined layout) also set how much rework you face later, so record them in the scope before any build starts.
Identity integration is the second common delay. On the Elastic side, SAML or OpenID Connect single sign-on sits in the Enterprise subscription tier according to Elastic's subscriptions page, so confirm the license level before designing role mappings. On OpenSearch, identity is configured through the security plugin, and the work is to define the authentication backend, map identity provider groups to backend roles, and then test that each role can see only the indices it should. Ask the implementer to show the role mapping and a denied-access test as acceptance evidence, not just a successful login. Detection content migration is the largest unknown. Rules written for one engine rarely port unchanged, so inventory every rule, saved search and dashboard, tag the ones that depend on engine-specific query syntax, and tune thresholds against your own traffic.
Parallel-run validation is where most projects extend their timelines. Run the old and new pipelines side by side long enough to compare alert counts, false positive rates and the ATT&CK coverage each detection provides, and define in advance what a pass looks like. Mapping and ingest pipeline rework often surfaces here, because field names that differ between the two stacks break queries silently. Retention and archiving design should be settled before the parallel run, since snapshot repositories and index lifecycle policies change what you can restore. DeployOpen plans and implements these pieces under a written, fixed scope, and the timeline follows from that scope, so ask any implementer to tie each phase to a named deliverable and acceptance test. Timelines and effort depend on your data volume, rule count and integration count, and they should be confirmed in a quote rather than assumed from this page.
What buyers ask before choosing or migrating
What does each option cost to run and what drives it up?
Neither engine has a license fee for the core search software in the way the question usually implies, but running either one is not free. OpenSearch is Apache-2.0, so the software itself carries no license charge. Elasticsearch is available under Elastic License 2.0, SSPL 1.0 or AGPLv3, and its paid subscription tiers add features on top. The recurring costs are infrastructure (compute, memory, disk and replicas), staff time to operate the cluster, upgrades, and any subscription or support contract. Storage growth is usually the largest driver, so ask any vendor or partner to model your daily ingest volume, retention period and replica count. Ask a quote to list one-time costs (design, build, migration, hardening) separately from recurring costs (hosting, support, upgrades, testing) and to state which Elastic features it assumes you license.
Does OpenSearch need a subscription for security analytics?
No. OpenSearch Security Analytics is part of the OpenSearch project and is documented as matching ingested logs against prepackaged or custom Sigma rules, recording findings and correlating them across log types. Because the software is Apache-2.0, you do not need an Elastic subscription to use it. Your real costs shift to infrastructure, rule tuning, alert handling and the people who run the cluster. Before you commit, confirm with the OpenSearch documentation which Security Analytics features your version supports, and test the rule set against your own log sources, since coverage depends on how well your fields map to the rules.
Which Elastic features need a paid tier and how do I confirm current tiers?
Elastic's self-managed subscription page places the detection engine, machine learning anomaly detection and case management under Platinum, and endpoint malware and ransomware prevention, host isolation and SAML or OpenID Connect single sign-on under Enterprise. Platinum is no longer sold to new customers, so any quote for those features should be checked against the current Enterprise offering. Tier boundaries change, so confirm them on the Elastic subscriptions page and get the features your use case depends on listed in writing by Elastic or your reseller before you design around them.
How long does a migration take and what decides it?
No supplied figure gives a migration duration, so treat any number you hear as unverified until it is scoped. The main drivers are the number of indices and index templates, the volume of data that must be moved or re-indexed, how many dashboards, alerts and integrations depend on Elasticsearch-specific APIs or features, the version you are moving from, and whether you can run both platforms in parallel during cutover. Ask for a written scope that lists each data source, each dashboard and alert, a test plan and a rollback plan. Fixed-scope work agreed in writing before it starts is the usual way to keep timelines and deliverables clear.
Can our team do the migration itself?
Often yes, if you have engineers who already run search clusters and a clear test plan. The work is mostly about mapping indices, templates, ingest pipelines, security roles, dashboards and alert rules, then validating results side by side. Teams with no recent experience of either platform, or with many dependent Elastic features, tend to underestimate the testing and cutover work. A useful check is to inventory every index, pipeline and alert, then ask whether each one can be recreated and verified within your staffing plan. DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted platforms in your own infrastructure, and most engagements are fixed-scope, so you can compare an in-house plan with a written external scope.
What does the work need from our staff?
Plan for staff time in several areas: cluster operations (capacity, shard management, snapshots and upgrades), security configuration (roles, authentication, TLS and audit logging), detection content (rule tuning and alert triage), and dashboards and integrations for your data sources. Name an owner for each area before work starts. Ask your partner which tasks transfer to your team at handover and which need ongoing support. Ongoing support, upgrades and continuous testing are available as retainers, which lets you split the work between internal staff and an outside team.
Is OpenSearch a drop-in replacement for Elasticsearch?
No, not in every case. OpenSearch is derived from Elasticsearch 7.10.2 and OpenSearch Dashboards is derived from Kibana 7.10.2, so the two share a common history, but they have diverged since then. Client libraries, API behavior, plugins, security features and Elastic-specific products may not behave the same way. Confirm compatibility for each client, plugin, integration and query you rely on, and test with your own data before cutover. The OpenSearch FAQ and the project's release notes are the right starting points for checking differences.
Does the choice change if we run Wazuh or Security Onion?
Yes, in several ways. Wazuh's indexer is an open source fork of OpenSearch and its dashboard is Apache-2.0, so a Wazuh deployment already runs on the OpenSearch lineage. Security Onion bundles Elasticsearch and Elastic Agent in one distribution, and its components moved to the Elastic License 2.0 starting with Security Onion 2.4, which forbids offering the software as a managed service. If you plan to run either distribution, the engine choice is largely made for you, and the decision moves to whether that distribution's licensing, hardware needs and feature tiers suit your monitoring model. Confirm the current license terms and hardware guidance in each project's documentation before you commit.
How DeployOpen helps choose, implement or migrate
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For OpenSearch vs Elasticsearch, we start with the licensing and feature questions that decide the platform, then carry the chosen path through to a documented, supported running system.
How we scope
- Written scope covers license obligations review, edition and feature mapping, and the search backend choice
- Scope names which security analytics, detection and SSO features your team requires before any build starts
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work begins
- Ask us to confirm the release line you will run, since current versions change over time
How we build
- Deploy the chosen platform in your environment, with cluster layout, storage and index lifecycle set to your retention needs
- Integrate log sources, identity providers and alerting, and test detection content against known events
- Run security testing against the deployment and record findings with remediation owners
- For a migration, plan index mapping, dual-running and cutover steps, and test rollback before any production change
How we hand over
- Deliver architecture, configuration and runbook documentation that your operations team can follow without us
- Provide compliance-readiness evidence that your auditors or certification bodies can review, since DeployOpen does not issue audit reports
- Walk your engineers through backup, upgrade and restore procedures, then confirm they can perform them
- Record the licensing position and edition features in use so future procurement decisions start from facts
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped in writing
- Upgrades are planned against the release lines your platform uses, with testing before each change
- Confirm with the vendor which subscription features you need, since those terms are set by the vendor and not by DeployOpen
- Ask for a quote built from the written scope, since DeployOpen does not publish a price list
