Blog

Introduction to Apache Solr

Key Takeaways

  • Apache Solr is a search platform built on Apache Lucene, with full-text search, faceting, and HTTP APIs.
  • SolrCloud distributes collections across shards and replicas, using ZooKeeper for cluster coordination—not index storage.
  • Search freshness and durability are separate concerns: soft commits make changes searchable, while hard commits persist Lucene index files.
  • Choose Solr when its search controls justify operating a search service. Keep authoritative application data outside the index and plan how to rebuild it.

Apache Solr adds a network-accessible search service around Apache Lucene's indexing and retrieval capabilities. Its core use cases are full-text search and faceted navigation: finding relevant documents, then narrowing results by attributes such as category, brand, or date.

The practical question isn't whether Solr can search your data. It's whether you need its relevance controls and distributed architecture enough to take on schema design, ingestion pipelines, and search-cluster operations.

What Is Apache Solr?

Lucene is a search library; Solr is the server platform built around it. Solr supplies HTTP endpoints, configuration, administration, and distributed operation so applications can use Lucene-backed search without embedding the library themselves.

For keyword search, an inverted index maps terms to the documents containing them. That lets the search engine find candidate documents through indexed terms rather than inspecting every document's text for every query. It isn't a universal performance guarantee: field design, filters, aggregations, data volume, and query shape still matter.

Solr can store and retrieve document fields, but treat it as a search index rather than your general-purpose transactional database. Keep authoritative records in an application database or another durable source, and make the index reproducible; schema changes can require reindexing. Solr is open source under the Apache License 2.0.

The October 2026 Version Baseline

As of October 17, 2026, Apache lists 10.x as Solr's current stable major line, with 10.0.0 as its available release, announced March 3, 2026. The more recently announced 9.11.0, released October 4, 2026, belongs to the previous major line; a newer announcement doesn't necessarily mean a newer major version.

Solr 10.0.0 uses Lucene 10.3 and requires Java 21 or later for the server. Solr and Lucene versions are coupled through the Solr distribution: upgrade the tested package, not individual Lucene JARs. The examples below target Solr 10.0.0, not preview documentation.

Apache Solr Features That Matter

Full-Text Search and Faceting

Field analysis controls how text becomes searchable terms. Tokenizers split text into tokens; filters can normalize those tokens, for example by lowercasing them. Choose analysis for the language and matching behavior your application needs.

Facets summarize the matching result set into buckets, such as counts by product category or price range. Solr's JSON Facet API also supports nested facets and statistical aggregations. Use separate field representations when you need both analyzed text for matching and intact values for category labels.

HTTP APIs, Administration, and Extensions

Solr exposes HTTP APIs, including JSON document updates and a JSON Request API for queries. It isn't one uniform REST resource model: request handlers, endpoints, and parameters determine each operation. JSON is convenient for application integration, while response writers also support formats including XML and CSV.

The Solr Admin UI is an operator/developer interface for inspecting collections, cores, configuration, field analysis, and query behavior—not a ready-made end-user search interface. Request handlers and search components provide extension points for customized search behavior.

A Search-Oriented SQL Interface

The optional sql module translates supported SQL queries into Streaming Expressions. Its facet aggregation mode pushes aggregation into the search engine; map_reduce distributes tuples to workers. This can serve reporting over indexed collections, but it isn't a relational database replacement: subqueries aren't supported, and queries without a LIMIT require projected fields to have DocValues.

Dense Vector and Hybrid Retrieval

Solr also supports dense numerical vectors and k-nearest-neighbor search through DenseVectorField and the knn query parser. Hybrid retrieval combines lexical matching with vector similarity, for example through reranking. Evaluate relevance, filtering behavior, memory requirements, and latency together; vector support alone isn't a reason to replace a working keyword-search system.

How Solr Works

From Source Documents to Search Results

  1. Define the schema. Fields specify types and properties such as whether values are indexed, stored, or multi-valued. Schemaless mode infers and adds field definitions; it doesn't eliminate the schema.
  2. Ingest documents. Your pipeline submits additions, updates, and deletes through update handlers. Design the pipeline to reconcile the index with its source.
  3. Analyze and index fields. Text analyzers produce terms used to build the Lucene index. Stored fields preserve values for retrieval.
  4. Parse and execute queries. A request handler invokes configured search components; a query parser interprets query syntax. Lucene matches and scores documents, while requested components can add facets, highlighting, or spell-check suggestions.
  5. Merge and return results. Distributed requests combine shard results, and a response writer serializes the response.
Authoritative data
  -> ingestion: additions / updates / deletes
  -> schema + field analysis
  -> Lucene indexes on shard replicas

Application query
  -> request handler + query parser
  -> shard-level matching, scoring, and facets
  -> coordinator merges results
  -> JSON response

For an application database feeding Solr, consider change data capture and indexing pipelines. Define stable document IDs, retry behavior, deletion handling, and an acceptable delay between source changes and search visibility.

Near-Real-Time Search: Visibility Versus Durability

An accepted update isn't necessarily visible to ordinary searches immediately. A soft commit makes index changes visible without synchronizing index files to stable storage. A hard commit synchronizes those files and rotates the transaction log; opening a new searcher is a separate option. Transaction logs also participate in recovery between hard commits.

Configure visibility and durability schedules around your requirements rather than issuing a hard commit after every document. Shorter visibility intervals have costs, and replica types affect freshness behavior. Test the complete write-to-search path rather than promising “instant” indexing.

SolrCloud: Collections, Shards, and Replicas

A collection is a logical search index. A shard contains a partition of its documents, and a replica is a physical copy of that shard, implemented as a Solr core. A node is a running Solr server and can host multiple cores.

Client -> any suitable Solr node coordinates the request

Logical collection: products
  Shard A                    Shard B
  Replica A1: leader         Replica B1: leader
  Replica A2                 Replica B2

Example physical placement:
  Node 1: A1, B2
  Node 2: A2, B1

ZooKeeper: cluster state, configuration, coordination
Solr replicas: Lucene index files

Each shard has a leader that coordinates updates. SolrCloud routes updates to the appropriate shard leader and supports automatic election of a replacement from eligible replicas. Replica type affects both leader eligibility and how copies receive index changes. ZooKeeper coordinates the cluster; it doesn't execute searches.

SolrCloud automates routing and parts of failover, not capacity planning. You still choose shard counts, replica types, placement, and recovery headroom. Don't assume adding a node automatically repartitions existing collections. Standalone, or user-managed, Solr leaves cluster coordination responsibilities to you rather than providing SolrCloud's coordination model.

Create a Collection and Search It Over HTTP

Prerequisites: a freshly extracted Solr 10.0.0 distribution, Java 21 or later, Bash, and curl. Run these blocks in order from the distribution directory as a non-root user, with no external ZooKeeper configured and ports 8983 and 9983 available.

1. Start Solr and Create the Collection

In Solr 10, bin/solr start defaults to SolrCloud mode. Without an external ZooKeeper connection, it starts an embedded ZooKeeper for this local setup. The collection command below creates one shard with one replica—no redundant copy.

set -e

SOLR_HOST_BIND=127.0.0.1 bin/solr start
bin/solr create -c books --shards 1 --replication-factor 1

BASE='http://localhost:8983/solr/books'

2. Define Text and Exact-Value Fields

Use the Schema API to define a small analyzer and two fields. Here, title uses standard tokenization and lowercasing; category uses the default configset's string type, which preserves the whole value without text analysis.

curl -fsS "$BASE/schema" \
  -H 'Content-Type: application/json' \
  --data-binary '{
    "add-field-type": {
      "name": "text_demo",
      "class": "solr.TextField",
      "analyzer": {
        "tokenizer": {"name": "standard"},
        "filters": [{"name": "lowercase"}]
      }
    },
    "add-field": [
      {
        "name": "title",
        "type": "text_demo",
        "indexed": true,
        "stored": true,
        "multiValued": false
      },
      {
        "name": "category",
        "type": "string",
        "indexed": true,
        "stored": true,
        "docValues": true,
        "multiValued": false
      }
    ]
  }'

This analyzer makes SOLR and Solr match the same title term. It doesn't add stemming or synonyms. Keeping categories intact means Search Books remains one facet value instead of becoming separate word buckets.

3. Index a Document and Query With a Facet

The update request uses a hard commit for a deterministic demonstration. The query uses Solr's documented JSON Request API. curl's -fsS options suppress the progress meter, report errors, and fail on HTTP error responses.

curl -fsS "$BASE/update?commit=true" \
  -H 'Content-Type: application/json' \
  --data-binary '[
    {
      "id": "book-1",
      "title": "Learning Apache Solr",
      "category": "Search Books"
    }
  ]'

curl -fsS "$BASE/query" \
  -H 'Content-Type: application/json' \
  --data-binary '{
    "query": "title:SOLR",
    "limit": 10,
    "fields": ["id", "title", "category", "score"],
    "facet": {
      "categories": {"type": "terms", "field": "category"}
    }
  }'

For this fresh collection, expect responseHeader.status to be 0, response.numFound to be 1, and response.docs to contain the book. The facets.categories.buckets array should contain Search Books with a count of 1.

Should I Use Solr?

Evaluate Solr when full-text relevance, faceted navigation, configurable analysis, and control over deployment are central requirements. Existing Solr expertise is a meaningful advantage. Don't choose it merely because your data is large or your application already runs across several servers.

Use this as a selection framework, not a feature-count contest. For background on another option, read our introduction to Elasticsearch.

OptionShortlist it whenValidate before choosing
SolrYou want its analysis, faceting, and extension model, especially with an experienced Solr team.Schema design, relevance tuning, ZooKeeper operations, recovery, and upgrade effort.
ElasticsearchYour team already works with Elasticsearch and Kibana, or its deployment ecosystem fits your organization.Required features, licensing, deployment-specific controls, and responsibility for operations.
OpenSearchIts search, ingestion, and Dashboards ecosystem matches your application and existing expertise.Query behavior, plugins, client compatibility, and migration effort against your actual workload.
Managed search serviceYou prefer to delegate infrastructure and some cluster lifecycle work.API coverage, extension restrictions, regional availability, costs, and data export. Managed offerings don't all expose the same controls.

Build a representative evaluation: production-like documents, judged queries, realistic filters and facets, concurrent indexing, and a node-failure test. Measure relevance and tail latency alongside recovery time and operational effort. If your search requirements are modest, evaluate your existing database's search facilities before adding another service.

What About Hadoop and HDFS?

Solr doesn't require Hadoop. More importantly, Solr 10 removed support for storing indexes and snapshots in HDFS, including the hdfs module. Older Solr documentation describing that deployment is historical, not guidance for the example above.

Keep ingestion from Hadoop-based systems separate from index storage. Any connector needs its own compatibility and maintenance review; don't assume universal Hive or HBase integration. Our Apache Hadoop architecture overview explains the separate storage and processing roles.

Production Checklist

  • Size total memory, not just heap. Leave room for filesystem caching and off-heap use; avoid assigning all host memory to the JVM. Benchmark representative documents and queries.
  • Budget disk and recovery capacity. Account for replicas, index merges, transaction logs, and rebuilding failed copies—not only the current index size.
  • Test backup and restore. Solr backups capture hard-committed data; changes visible only through a soft commit may be absent. Replication isn't a substitute for an independently tested restore path.
  • Rehearse upgrades and reindexing. Review the upgrade notes for every intervening release, and compare relevance as well as availability. Changes to field analysis generally require rebuilding affected indexed data.
  • Monitor the service and the pipeline. Track request latency, errors, heap and garbage collection, disk pressure, replica state, and source-to-search lag. Solr exposes JVM, node, core, and request metrics.
  • Establish a security boundary. Configure authentication, authorization, and TLS; restrict Solr and ZooKeeper to trusted networks. Test denied access, not just successful logins. The Admin UI and other Solr APIs aren't designed for direct exposure to untrusted parties.

FAQ

What is Apache Solr used for?

Apache Solr provides full-text search, faceting, highlighting, and distributed indexing for search applications. Evaluate it when you need control over field analysis, relevance, and faceted navigation.

What is the difference between Solr and Lucene?

Lucene is a search library embedded in an application; Solr is a server platform built on Lucene. Solr adds HTTP APIs, administration, configuration, and distributed operation through SolrCloud.

Is Apache Solr a database or a search engine?

Solr is primarily a search and indexing system that can also store and retrieve document fields. Treat it as a derived search index, not a replacement for your application's transactional system of record, and retain a way to rebuild it.

How does SolrCloud handle sharding and replication?

SolrCloud divides a collection into logical shards and maintains physical replicas of those shards. A leader coordinates updates for each shard, with ZooKeeper supporting cluster coordination and leader election; operators still plan capacity, placement, and recovery.

Does Solr run on HDFS or integrate with Hadoop?

Solr doesn't require Hadoop, and Solr 10 removed HDFS support for index and snapshot storage. A pipeline can still ingest data originating in Hadoop-based systems, but connector compatibility must be evaluated separately from SolrCloud deployment.

Further Reading

Written by Sam Erickson

Software engineer. I write every article on StackChief myself. More about me