Solr vs. Elasticsearch / OpenSearch

This section documents the current Solr line (10.0; 9.10.x the maintained 9.x branch), written and verified against the Apache Solr Reference Guide. No specific patch version is pinned. Some capabilities (the Solr Operator on Kubernetes, the package-manager ecosystem, Learning To Rank model training, and expert plugin development) 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.

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

Solr and Elasticsearch both wrap Apache Lucene in a distributed search server, and on paper they cover the same ground: index JSON documents, get relevance-ranked full text back, facet and aggregate over the results, scale out with shards and replicas. In practice the two projects have diverged in API philosophy, in which capabilities they lead on, in how they coordinate a cluster, and — since 2021 — in licensing. This page is the head-to-head; it does not re-explain what a search engine is for or how an inverted index works — see its Full-Text Search Engines section — and it does not re-document Elasticsearch itself (see Elasticsearch Reference). What follows assumes you already know you want a Lucene-based search engine and are choosing which one.

Same Core, Different Philosophy

Both engines embed the same Lucene library for tokenization, the inverted index, segment merging, and BM25 scoring — a well-built query in one has a close analogue in the other, and the underlying storage-and-merge behaviour (segments, commits, near-real-time visibility) is shared. The projects part ways above that layer:

  • Solr configures a collection through files — schema.xml (or the managed schema), solrconfig.xml — or the equivalent Schema/Config APIs, and centralizes that configuration in ZooKeeper for the whole cluster to read. Request handling is built around named, pre-configured request handlers (/select, /update, /stream) that you point a request at rather than a single endpoint that branches on payload shape. See What Apache Solr is & how to run it and Core concepts & architecture for the mechanics.

  • Elasticsearch is JSON-native end to end: the mapping is a JSON document, every query is a JSON body against a small, uniform set of REST endpoints (_search, _doc, _bulk), and its official clients in most mainstream languages mirror that JSON shape directly into typed request/response objects.

Neither philosophy is strictly better — explicit, versioned, file-based configuration is easier to diff and review in source control; a uniform JSON-body API is easier to generate, template, and bind to a typed client library.

Where Solr Leads

  • The JSON Facet API (json.facet) nests arbitrary metric, terms, range, and query facets to any depth, with a domain that can widen, narrow, or join across a block-join relationship, plus relatedness() for "what stands out" analysis — see Faceting. Elasticsearch’s bucket/metric/pipeline aggregations cover overlapping ground but nest differently and have no direct equivalent to relatedness().

  • Streaming expressions and Parallel SQL turn Solr into a composable data-processing engine: stream sources, decorators (hashJoin, rollup, having), math evaluators, graph traversal (nodes/gatherNodes), and a /sql handler that lets ordinary JDBC/SQL clients run against the same streaming engine — see Streaming expressions & Parallel SQL. This is a capability class Elasticsearch does not have a direct match for (ES|QL, below, is a different design aimed at ad-hoc piped querying rather than a JDBC-facing streaming/join engine).

  • Learning To Rank (LTR) ships as a first-class contrib module for re-ranking results with a trained model, feature store and all — see Relevance & scoring. Elasticsearch’s equivalent (Learning To Rank) has moved between a plugin and a paid feature across releases; check the current licensing tier before depending on it.

  • Pluggable everything. Query parsers, request handlers, update processors, similarity implementations, and codecs are all swappable via configuration or a custom SolrCoreAware/factory class, which suits teams that want to extend the server itself rather than only its documents and queries.

  • License. Apache Solr has been Apache-2.0, unconditionally, for its entire history — see Licensing History below.

Where Elasticsearch Leads

  • A JSON-native client story. One request/response shape, a small set of endpoints, and official clients that map that shape into idiomatic types in most mainstream languages — generally less boilerplate than composing a Solr request handler call for the same result.

  • Aggregations are deeply integrated with the query DSL and near-ubiquitous in the ecosystem’s tooling (Kibana dashboards, in particular), and cover metric, bucket, and pipeline analytics over the same result set a search ran against.

  • ES|QL, a piped query language (FROM …​ | WHERE …​ | STATS …​) for ad-hoc exploration and transformation directly against indices, without hand-building a JSON query body.

  • Ingest pipelines run processors (grok, dissect, date, geoip, enrich, scripted steps) on documents at write time, inside the cluster, without a separate ETL hop.

  • Index Lifecycle Management (ILM) and data streams automate the roll-over, shrink, and eventual deletion of time-based indices (logs, metrics) — a scenario Solr handles by hand or with external tooling rather than a built-in lifecycle manager.

  • Managed-service reach. Elastic Cloud, Amazon OpenSearch Service, and several third-party providers offer Elasticsearch/OpenSearch as a managed product; Solr’s managed-hosting options are comparatively sparse, though the Solr Operator covers self-managed Kubernetes deployments.

Operations: ZooKeeper vs. Built-In Coordination

SolrCloud delegates cluster state, leader election, and configuration distribution to an external Apache ZooKeeper ensemble — see SolrCloud architecture. That is one more stateful service to run, monitor, and keep healthy (an odd-sized ensemble, its own quorum and disk requirements), but it is also a mature, well-understood piece of infrastructure that many platform teams already operate for other systems.

Elasticsearch elects a master node and distributes cluster state internally, with no separate coordination service to deploy. That removes one moving part, at the cost of the cluster’s coordination layer being entirely internal to Elasticsearch itself — there is nothing external to inspect with generic ZooKeeper tooling if something goes wrong.

Neither model is inherently more reliable; the practical question is whether your team already runs ZooKeeper (in which case SolrCloud adds little marginal operational cost) or would rather not add it at all.

Licensing History

Solr has been licensed under the Apache License 2.0 for its entire history, with no change in that status. It has been governed as an Apache Software Foundation top-level project throughout.

Elasticsearch has not stayed on one license. It started Apache-2.0 as well, but in January 2021 Elastic relicensed future versions of Elasticsearch and Kibana away from Apache-2.0, offering them under a choice of the Server Side Public License (SSPL) or the proprietary Elastic License, neither of which the Open Source Initiative recognizes as open source. In April 2021, AWS forked the last Apache-2.0 version (Elasticsearch 7.10.2) as the OpenSearch project, continuing it under Apache-2.0; OpenSearch has since moved to its own foundation governance. In 2024, Elastic added the GNU Affero General Public License v3 (AGPL) as a third licensing option alongside SSPL and the Elastic License for Elasticsearch and Kibana, restoring an OSI-approved open-source option for users who want one.

The practical upshot: if a strict, unconditional Apache-2.0 license is a hard requirement, Solr has always satisfied it; Elasticsearch itself requires accepting SSPL, the Elastic License, or (since 2024) AGPL, while its OpenSearch fork remains Apache-2.0.

Momentum and Community Trend

Popularity and contributor mindshare have shifted since the 2021 license change and the OpenSearch fork — Elasticsearch/OpenSearch usage grew relative to Solr’s over that period in most public trackers. Rather than repeat a specific ranking snapshot here (any number quoted today will be stale by the time you read it), check the DB-Engines popularity trend for Elasticsearch vs. Solr directly for the current picture. Treat any single ranking site as one signal, not a verdict — popularity trend and fitness for your specific workload are different questions.

Is Solr Discontinued? No — Only Spring Data Solr Is

This is the single most common point of confusion in this comparison, so it is worth stating plainly:

Apache Solr itself is an actively developed, top-level Apache Software Foundation project — not discontinued, deprecated, or in maintenance-only mode. See What Apache Solr is & how to run it for the release line these pages track.

What actually was discontinued is a Spring integration project: Spring Data for Apache Solr. Announced in this April 2020 post, Spring Data Solr was retired and moved to the Spring Attic. The practical consequence lives entirely on the Spring Boot integration side, not on Solr’s side: there is no Spring Boot auto-configuration for Solr, no spring-boot-starter-data-solr, and no repository abstraction over Solr the way Spring Data still provides for Elasticsearch. SolrJ — Solr’s own Java client — is the only supported integration path for a JVM application today; see Spring Boot integration with SolrJ for what that looks like in practice.

Conflating the two — "Spring Data Solr is discontinued" becoming "Solr is discontinued" — is a common and understandable mistake, since the retirement announcement is easy to skim past the word "Spring." They are unrelated facts: one Apache project (Solr) is thriving; one Spring integration library for it was retired five years into Solr’s life and never replaced with an equivalent.

A Quick Side-by-Side

The same "index a document, then search it" round-trip against both engines, to make the API-philosophy difference concrete:

# Solr: JSON body to a named request handler under a collection.
curl -X POST 'http://localhost:8983/solr/books/update?commit=true' \
  -H 'Content-Type: application/json' \
  -d '[{"id": "1", "title": "The Left Hand of Darkness", "author_s": "Ursula K. Le Guin"}]'

curl 'http://localhost:8983/solr/books/select?q=title:darkness'

# Elasticsearch: JSON body to a REST verb against an index.
curl -X POST 'http://localhost:9200/books/_doc/1' \
  -H 'Content-Type: application/json' \
  -d '{"title": "The Left Hand of Darkness", "author": "Ursula K. Le Guin"}'

curl -X GET 'http://localhost:9200/books/_search' \
  -H 'Content-Type: application/json' \
  -d '{"query": {"match": {"title": "darkness"}}}'

Both round-trips do the same thing — write one document, then run one relevance-ranked query — in roughly the same number of characters. The visible difference is Solr’s request-handler-plus-parameters shape (/update, /select?q=…​) against Elasticsearch’s uniform _doc/_search endpoints with the query itself always expressed as a JSON body. Neither shape generalizes better than the other; which one reads more naturally is largely a matter of which ecosystem your team already writes clients against.

Choosing, and When Not to Migrate

For a new system with no existing investment in either engine, weigh the per-side strengths above against what the workload actually needs: streaming/graph/SQL-style processing and Learning To Rank point at Solr; a JSON-native client story, heavy aggregation/analytics use, ES|QL, or a managed-service target point at Elasticsearch/OpenSearch. An unconditional Apache-2.0 requirement is decided the moment it is stated — Solr satisfies it outright, and OpenSearch (not Elasticsearch itself) is the Apache-2.0 option on the other side.

For a team already running one of the two in production, the calculus is different: a working, tuned, monitored cluster with a schema and query set your application already depends on is not worth uprooting for feature parity you may not use. Migrating means a full reindex, a rewrite of every query and every piece of client code, and a period of running both systems in parallel — real cost that a head-to-head feature comparison does not capture. Migrate only when a specific, named capability gap is actually blocking a requirement (for example: you need ILM-style automated index lifecycle management for time-series logs and are unwilling to build it yourself, or you need streaming expressions and Parallel SQL and have no equivalent today) — not because a comparison page, this one included, made the other engine sound more capable in the abstract.

See Deployment & upgrades for upgrading within the Solr line rather than off it, and Choosing the Right Database for how a search engine (either one) fits alongside the rest of a polyglot-persistence architecture.