Lucene vs. Solr vs. Elasticsearch vs. OpenSearch

This section documents the current Apache Lucene 10.x line — Lucene 10 requires Java 21 — as published at the Apache Lucene documentation and Javadoc, which is the reference these pages are written and verified against. No specific patch version is pinned; examples target lucene-core 10.x and the companion modules. Some areas (the Panama foreign-memory / Vector API internals, codec file-format internals, and the nightly benchmark harness) are linked, not documented in depth.

This content was generated with the assistance of AI and should be verified against the official documentation before being relied on in production, as Lucene iterates quickly.

This section’s bibliography lists the reference material consulted while preparing these pages.

Apache Lucene is the search engine inside Apache Solr, Elasticsearch and OpenSearch: the same inverted index, analysis chain, query evaluation and BM25 scoring runs in all four. What differs is everything around the library — whether you get a JAR or a clustered server, a Java API or a REST protocol, and who carries the operational burden. This page contrasts the four so you can pick the right layer to build on.

The four options at a glance

Apache Lucene Apache Solr Elasticsearch OpenSearch

What it is

Embedded Java library, in-process

Search server around Lucene

Search server around Lucene

Search server around Lucene (fork of Elasticsearch 7.10)

Interface

Java API, direct method calls

HTTP + JSON/XML, named request handlers

REST + JSON, uniform endpoints

REST + JSON (Elasticsearch 7.10 baseline, now diverging)

Distribution

Single JVM; you build sharding / replication

SolrCloud + Apache ZooKeeper

Built-in cluster coordination

Built-in cluster coordination

Batteries included

None — index, query and scoring only

Faceting, dismax, suggesters, LTR, streaming expressions

ILM, ingest pipelines, security, Kibana, ES|QL

ISM, ingest pipelines, security, OpenSearch Dashboards

License

Apache-2.0

Apache-2.0

SSPL / Elastic License v2 (7.11+); AGPL option added 2024

Apache-2.0

Deployment weight

Lowest — it is a dependency

Server plus a ZooKeeper ensemble

Server (JVM, resource-hungry)

Server (JVM, resource-hungry)

Admin UI / REST

None

Solr Admin UI + APIs

Kibana + REST

OpenSearch Dashboards + REST

Apache Lucene — the embedded library

You add lucene-core to a JVM application and call it directly. No process to deploy, no port, no wire protocol, no serialization hop between your code and the index — which is why an in-process Lucene search is the lowest-latency option and gives you total control over analysis, scoring, collectors and codecs. The footprint is a few megabytes of JARs. See the Apache Lucene core documentation for what the library is.

// The whole "search engine" is these objects, running in your process.
// https://lucene.apache.org/core/10_0_0/core/org/apache/lucene/search/IndexSearcher.html
try (Directory dir = FSDirectory.open(Path.of("index"));
     IndexReader reader = DirectoryReader.open(dir)) {
  IndexSearcher searcher = new IndexSearcher(reader);
  TopDocs hits = searcher.search(new TermQuery(new Term("title", "darkness")), 10);
}

The cost is everything a server would hand you: Lucene is single-node, so sharding, replication, failover, a query protocol, an admin UI, authentication, and snapshot / restore are yours to build or to borrow (the replicator module is a starting point, not a finished system). It is JVM-only, and the API surface is large — the learning curve is steeper than sending JSON to a REST endpoint. See Getting started and Architecture & data flow.

Apache Solr — the search server

Solr wraps Lucene in an HTTP server with mature faceting (the JSON Facet API), the dismax / edismax query parsers, spell-check and suggesters, Learning To Rank, and streaming expressions. A collection is configured through schema.xml / solrconfig.xml files (or the equivalent APIs); SolrCloud distributes that configuration and cluster state through an Apache ZooKeeper ensemble. Solr has always been Apache-2.0.

# Index and query over HTTP -- no client library required.
curl 'http://localhost:8983/solr/books/update?commit=true' -H 'Content-Type: application/json' \
  -d '[{"id":"1","title":"The Left Hand of Darkness"}]'
curl 'http://localhost:8983/solr/books/select?q=title:darkness'
# https://solr.apache.org/guide/solr/latest/getting-started/introduction.html

The trade-off is operational weight — a server plus a ZooKeeper quorum to run and monitor — and a config-file-driven model that is more to learn up front but versions cleanly in source control. See Apache Solr Reference and its architecture page.

Elasticsearch — the REST server with batteries

Elasticsearch is JSON-native end to end: every mapping and query is a JSON document against a small set of REST endpoints, cluster coordination is built in (no ZooKeeper), and a large amount of operational tooling ships in the box — Index Lifecycle Management, ingest pipelines, a security layer, ES|QL, and Kibana for visualization.

curl -X PUT 'http://localhost:9200/books/_doc/1' -H 'Content-Type: application/json' \
  -d '{"title":"The Left Hand of Darkness"}'
curl 'http://localhost:9200/books/_search' -H 'Content-Type: application/json' \
  -d '{"query":{"match":{"title":"darkness"}}}'
# https://www.elastic.co/guide/en/elasticsearch/reference/current/elasticsearch-intro.html

The costs: it is resource-hungry (heap, CPU, disk), the API moves quickly across minor versions, and since version 7.11 Elasticsearch is no longer Apache-2.0 — it is offered under the SSPL or the Elastic License v2, with AGPL added as a third option in 2024. See Elasticsearch Reference.

OpenSearch — the Apache-2.0 fork

When Elastic relicensed, AWS forked the last Apache-2.0 release (Elasticsearch 7.10.2) as OpenSearch, continuing it under Apache-2.0 with its own governance. It keeps the Elasticsearch 7.10 REST API as a baseline and adds its own equivalents — OpenSearch Dashboards (a Kibana fork), Index State Management (ISM) in place of ILM, and its own security and observability plugins.

The costs: the API has diverged from Elasticsearch since 7.10 and the gap widens each release, so "Elasticsearch-compatible" is decreasingly literal; the community and plugin ecosystem are smaller than Elastic’s. See the OpenSearch project overview.

When to use which

  • Reach for Lucene directly when the search runs inside one JVM service, latency matters more than operational features, the corpus fits comfortably on one node (or you already have a sharding strategy), and you want to control analysis / scoring / collectors down to the class — desktop apps, search embedded in a product, a single-service "search this table" feature.

  • Reach for Solr when you want a server (multiple clients, language-agnostic HTTP) with strong faceting, streaming / graph / SQL-style processing or first-class Learning To Rank, an unconditional Apache-2.0 license, and you either already run ZooKeeper or do not mind adding it.

  • Reach for Elasticsearch when you want a server with the least assembly required — built-in clustering, lifecycle management, ingest, security and Kibana — heavy aggregation / analytics use, or a managed offering, and the SSPL / Elastic / AGPL licensing is acceptable.

  • Reach for OpenSearch when you want that same server experience but need Apache-2.0, or you are on AWS and want the managed OpenSearch Service.

If you cannot yet tell whether you need a library or a server at all, work through Choosing the Right Database first.

They all embed Lucene

Solr, Elasticsearch and OpenSearch are layers on top of the same library. A TextField vs. StringField decision, the analysis chain, BooleanQuery structure, BM25 tuning, DocValues for sorting, segment merging, near-real-time visibility — every concept in this section is the same concept the servers expose one layer up, under a different name (a "mapping" is field configuration, an "analyzer" is an analyzer, a "filter clause" is a FILTER BooleanClause). Learning Lucene makes all three servers less mysterious.

Your application on top of Lucene directly or via Solr

Related pages