Elasticsearch vs OpenSearch (2026)：分叉、许可证与自托管选择

如果你是一个自托管者，想要一个拥有完全可控许可证的搜索引擎，OpenSearch 通常是更安全的长期选择——它采用 Apache-2.0 许可，并由中立的基金会（隶属于 Linux 基金会的 OpenSearch 软件基金会）治理，因此没有单一供应商能单方面更改许可条款。Elasticsearch 是原始引擎，仍然是功能和生态的领导者，但它由 Elastic 控制，采用 AGPLv3 / Elastic License v2 / SSPL 三许可——在基于它进行构建之前，你应该仔细阅读这些条款。两者共享同一个祖先：OpenSearch 是 AWS 在 2021 年对 Elasticsearch（和 Kibana）的分叉，因为 Elastic 离开了 Apache-2.0。这份对比就是讲述这个分叉故事，为那些决定自托管哪一个的人而写。

这是一场搜索引擎对搜索引擎的对比，但两者也支持向量搜索，因此它属于我们的向量数据库比较系列。如果你的任务是为 RAG 做纯语义检索，而不是一个完整的搜索/分析平台，那么专用的向量引擎通常是更轻量的工具——请参考最佳自托管向量数据库和Qdrant vs Pinecone。关于向量数据库的概念，请参阅什么是向量数据库。

并列对比

	Elasticsearch	OpenSearch
起源	原始引擎（Elastic，2010）	AWS 对 Elasticsearch/Kibana 7.10 的分叉（2021 年 1 月宣布，2021 年 7 月 GA）
许可证	AGPLv3 / Elastic License v2 / SSPL（三许可）	Apache-2.0
治理	Elastic（单一供应商）	OpenSearch 软件基金会，隶属于 Linux 基金会
核心语言	Java	Java
GitHub 星标（2026 年 6 月）	77.1k	13.2k
向量搜索	是——稠密向量 / kNN（基于 Lucene）	是——向量引擎 / k-NN（Lucene, FAISS, NMSLIB）
自托管	是——你的基础设施	是——你的基础设施
原厂商托管	Elastic Cloud	AWS（Amazon OpenSearch Service）及其他

星标数量是 GitHub 在 2026 年 6 月的取整数字，会随时间变化——请注意，原始星标数量部分反映了仓库年龄（Elasticsearch 早得多），所以将其视为覆盖范围的粗略代理，而非质量排名。许可证和治理是对自托管者最重要的稳定事实。

分叉故事（为什么有两个）

Elasticsearch 在最初的十年里一直采用 Apache-2.0 许可，成为默认的开源搜索引擎，被广泛采用，包括云提供商（尤其是 AWS）在其基础上提供托管服务。

在 2021 年（7.11 版本），Elastic 重新许可了源码：Apache-2.0 的代码变为 Server Side Public License (SSPL) 和 Elastic License 的双许可，部分原因是为了阻止云提供商提供 Elasticsearch 作为竞争性托管服务。SSPL 是一种 copyleft 许可证，但未经 OSI 批准，不被视为开源。

作为回应，AWS 分叉了 Elasticsearch 和 Kibana 7.10（最后一个 Apache-2.0 版本），在 2021 年 1 月宣布了 OpenSearch，并在 2021 年 7 月发布了 1.0 版本用于生产，保持其采用 Apache-2.0。

在 2024 年，Elastic 添加了 AGPLv3——一个 OSI 批准的开源许可证——作为除 ELv2 和 SSPL 之外的第三个选项，为 Elasticsearch 恢复了一条开源路径（这有时被称为 Elastic 的“回归开源”）。而在 2024–2025 年，OpenSearch 从 AWS 的监管转移到了中立的基金会：OpenSearch 软件基金会，隶属于 Linux 基金会。

对于自托管者来说，结论是：Elasticsearch 再次开源可用（你可以选择 AGPLv3），但它仍然由单一供应商控制，采用你必须斟酌的三许可。OpenSearch 是纯粹的 Apache-2.0，由中立基金会治理——你专门选择它正是因为没有任何公司能单方面更改条款。

许可证与治理：决策的核心

对于自托管者来说，这是整个选择所围绕的维度。

• Elasticsearch — AGPLv3 / Elastic License v2 / SSPL（三许可），单一供应商。 你要选择使用三个条款中的哪一个。AGPLv3 是 OSI 批准的开源许可证，但属于强 copyleft——将修改版本作为网络服务运行可能会触发源码可用义务，一些组织为规避风险会避免使用。ELv2 是源码可用，但限制将其作为竞争性托管服务提供。SSPL 是 copyleft 且未经 OSI 批准（不被视为开源）。所有三个都由 Elastic 控制，一个单一供应商——这正是最早导致 2021 年重新许可的安排。
• OpenSearch — Apache-2.0，中立基金会。 单一、宽松、OSI 批准的许可证，没有 copyleft，也没有 SaaS 限制，由 **OpenSearch 软件基金会（Linux 基金会）**治理。没有贡献者许可协议，关键是，没有任何公司能单方面对你重新许可。对于一个想要“我们能控制的许可证”的团队来说，这种组合——宽松许可证加上中立治理——就是全部卖点。

诚实地讲：如果许可证的简单性和免受供应商未来重新许可的保护是你的优先事项，OpenSearch 在基金会下的 Apache-2.0 是风险更低的选择。如果 AGPLv3（或 ELv2/SSPL）符合你的部署方式，并且你重视 Elastic 的路线图，那么 Elasticsearch 是完全可用的开源可用软件——你只需要仔细确认许可证条款与你的部署相符。

功能与向量搜索

两者都是成熟、基于 Lucene 的搜索与分析引擎：全文搜索、聚合/分析、仪表板（Elasticsearch 的 Kibana，OpenSearch 的 OpenSearch 仪表板——它本身就是 Kibana 的分叉），以及摄取/可观测性生态系统。

在向量搜索方面，两者都真正有能力：

• Elasticsearch 支持基于 Lucene 的稠密向量字段和 kNN 搜索，具有混合（关键词+向量）检索，并且 Elastic 在其 AI 搜索定位中大力投资向量/语义功能。
• OpenSearch 提供专用的向量引擎，支持由 Lucene、FAISS 和 NMSLIB 驱动的 k-NN 搜索，以及混合搜索和 ML 功能。最近的版本强调了向量搜索性能工作（例如更快的并发 k-NN 搜索）。

由于两者共享 7.10 祖先，基线功能集重叠较多。但自 2021 年以来它们已经分化——功能不再完全对等，API 和新功能也不同，新的功能不保证直接兼容。实际解读：两者都能很好地处理全文和向量搜索；根据许可证、治理、生态系统和托管服务契合度来选择，而不是假设它们可互换。

对于 RAG 构建者有一点需要注意：像这样完整的搜索/分析平台比专用向量数据库更重。如果语义检索是唯一任务，专用的引擎（见最佳自托管向量数据库和Qdrant vs Pinecone）通常运行起来更轻量。当你想要全文搜索、分析、日志/可观测性以及向量功能整合在一个平台时，才选择 Elasticsearch/OpenSearch。

性能

两者都是基于 Java/Lucene 的引擎，架构大体相似，而且由于 OpenSearch 始于一个分叉，它们的基线性能特征相似。此后各自独立优化，你会看到双方都发布了供应商性能基准——对所有这些都要持通常的怀疑态度，因为搜索性能在很大程度上取决于数据形状、查询混合、映射/索引设计、JVM 调优和硬件，而基准测试通常由有利益关系的方运行。

合理的结论：对于大多数工作负载，引擎本身不会成为瓶颈——你的映射、查询设计、分片策略和 JVM/硬件规格才是决定因素。在你自己的数据和查询模式上做基准测试，而不是根据任何一方的标称数字做选择。

自托管与运维

两者都可以在自有基础设施上自托管，并且都带有基于 JVM 和 Lucene 的搜索集群的典型运维负担——这比像 Meilisearch 这样的单二进制引擎或像 Qdrant 这样的单镜像向量数据库要重。

• 需要运行 JVM，调优堆和垃圾回收，规划分片和副本，并操作多节点集群以实现生产弹性。两者都提供了 Docker 镜像和 Helm chart，并拥有庞大的运维社区。
• Elasticsearch 自托管意味着在你选择的许可（AGPLv3/ELv2/SSPL）下运行发行版，并自己运维，独立于 Elastic Cloud。
• OpenSearch 自托管是纯粹的 Apache-2.0，无需做许可决定，也无需担心 SaaS 限制——如果你有一天可能将其作为服务的一部分提供，这是一个有意义的简化。

两者的运维工作量相当；对自托管者而言，重要的区别是你所使用的许可证，而不是日常运维，两者类似。如果要求是“我想无限期地自己运行，且许可证不能被任何人单方面更改”，那么 OpenSearch 的 Apache-2.0 是更清晰的答案。

成本与定价

两种引擎都免费自托管——成本在于它们运行的基础设施。一个 Lucene/JVM 搜索集群比单二进制站点搜索引擎重，因此需要为生产规模规划 RAM/堆和多节点；这比适合 Meilisearch 或小型向量索引的 ~$20–30/月 VPS 要大。

在托管方面：

• Elasticsearch → Elastic Cloud，Elastic 自己的托管产品（外加在你选择的许可证下自我管理）。
• OpenSearch → Amazon OpenSearch Service 和其他提供商，因为其 Apache-2.0 许可证允许第三方将其作为托管服务提供——正是这种开放性（2021 年重新许可意在阻止的）意味着 OpenSearch 的托管服务竞争更激烈。

自托管的成本故事两者相似。许可证改变的是战略成本图景：使用 OpenSearch，你永远不会因为一个重新许可公告就被迫做出决定，并且如果你想要卸下运维，你有一个竞争激烈的托管服务市场。

何时选择哪个

选择 OpenSearch，如果你：

• 想要宽松、OSI 批准的许可证（Apache-2.0），无 copyleft 和无 SaaS 限制。
• 想要中立、基金会治理（Linux 基金会），因此没有任何单一供应商能对你重新许可。
• 想要一个竞争性的托管服务市场（AWS 等）作为后备。
• 优先考虑“一个我们能长期完全控制的许可证和项目”。

选择 Elasticsearch，如果你：

• 想要原始引擎、其最新功能和最大的生态系统，并且 AGPLv3（或 ELv2/SSPL）符合你的部署。
• 你已经投资了 Elastic Stack（Kibana、集成、Elastic Cloud），并重视 Elastic 的路线图。
• 你的法务团队已确认你将使用的许可证适合你的部署方式。

结论

对于一个优先考虑可控制许可证的自托管者来说，OpenSearch 是更安全的长期选择——纯粹的 Apache-2.0、Linux 基金会下的中立治理、能力强大的向量搜索，并且没有单一供应商能单方面更改条款。这正是它被分叉出来所要提供的场景。Elasticsearch 仍然是功能和生态系统领导者，通过 AGPLv3 再次开源可用，当你想要其最新能力和 Elastic Stack 时是一个优秀的选择——前提是你已确认 AGPLv3（或 ELv2/SSPL）符合你的部署方式。对大多数自托管者来说，决定性问题不是原始性能——两者很接近，拥有共同祖先——而是你希望在未来十年建立在哪个许可证和治理模型之上。OpenSearch 的答案是“中立治理下的宽松许可证”；Elasticsearch 的答案是“基于 Elastic 条款的领先引擎和生态系统”。

常见问题

OpenSearch 与 Elasticsearch 相同吗？ 不再相同。OpenSearch 始于 2021 年，是 AWS 对 Elasticsearch 和 Kibana 最后一个 Apache-2.0 版本（7.10）的分叉，因此它们共享一个祖先和许多基线行为。但此后它们已经分化——不同的许可证、治理和更新功能——因此对于最新功能不再直接兼容。请精心规划迁移，而不是假设可互换。

为什么创建 OpenSearch？ 因为 Elastic 在 2021 年将 Elasticsearch 从 Apache-2.0 重新许可（改为 SSPL + Elastic License），部分原因是为了阻止云提供商将其作为托管服务提供。AWS 分叉了最后一个 Apache-2.0 版本，以保持一个开放许可的引擎继续发展，现在 OpenSearch 由 Linux 基金会下的 OpenSearch 软件基金会治理。

2026 年 Elasticsearch 使用什么许可证？ Elasticsearch 是三许可：AGPLv3（OSI 批准的开源许可证，于 2024 年添加）、Elastic License v2（源码可用，限制竞争性托管服务）和 SSPL（copyleft，未获 OSI 批准）。你可以选择使用哪个条款。相比之下，OpenSearch 是纯粹的 Apache-2.0。

两者都支持 RAG 的向量搜索吗？ 是的。Elasticsearch 支持基于 Lucene 的稠密向量 kNN 搜索，具有混合检索功能；OpenSearch 提供了向量引擎，由 Lucene、FAISS 和 NMSLIB 支持的 k-NN。两者都可用于语义检索。不过，完整的搜索/分析平台比专用向量数据库更重——如果 RAG 是唯一任务，像 Qdrant 这样的专用引擎通常运行起来更轻量。请参阅最佳自托管向量数据库。

自托管 Elasticsearch 还是 OpenSearch 哪个更好？ 两者都是可自托管的 Java/Lucene 引擎，运维负担相当（JVM、堆调优、多节点集群）。对自托管者来说，重要的区别是许可证：OpenSearch 是 Apache-2.0，在中立基金会治理下，因此没有任何供应商能单方面更改条款——如果“我们能控制的许可证”是优先考虑，这是风险较低的选择。如果 AGPLv3（或 ELv2/SSPL）符合你的部署方式，并且你想要其最新功能，Elasticsearch 也是一个很好的自托管引擎。

---

Aquila 是私有、自托管 AI 搜索的独立指南——搜索由你拥有，而非租用。如果纯语义检索是你的任务，请在 Qdrant vs Pinecone 和最佳自托管向量数据库中比较专用引擎，或在什么是向量数据库中学习基础知识。掌控你自己的搜索。