Configuring Apache Solr for faster searchfor Drupal 11 , 10 , 9 , and 8

Last updated :  

Database-backed search (the default Search API backend) runs full-text queries through your normal database — fine at small scale, genuinely limiting once content volume and query complexity grow. Apache Solr is a dedicated search engine built specifically for this problem: purpose-built indexing structures, real relevance ranking, and query performance that doesn't compete with your site's own database load at all, since it's an entirely separate service.

What you'll learn in this lesson

  • Why Solr is architecturally faster than database-backed search, not just "better tuned"
  • Connecting Search API to a Solr server
  • The schema alignment step people skip, and why it breaks things

Why Solr wins architecturally

Solr builds inverted indexes specifically optimized for full-text search — data structures that map each term directly to the documents containing it, purpose-built for exactly the kind of query search needs. A relational database's indexes are general-purpose, not specialized for full-text relevance ranking the way Solr's are. This is a real architectural difference, not just "Solr happens to be configured better" — even a well-tuned database backend has a lower ceiling for search-specific query performance.

Connecting Search API to Solr

composer require drupal/search_api_solr
drush en search_api_solr -y
// Configure a Solr server entity pointing at your running Solr instance.
// /admin/config/search/search-api/server/add
// Connector: Standard, Host: localhost, Port: 8983, Core: drupal

Solr itself runs as a separate service (its own Java process, typically on its own port) — this is infrastructure you provision alongside your web server and database, not something that lives inside Drupal's own codebase.

The schema alignment step people skip: Search API Solr ships a specific Solr schema configuration that must be deployed to your actual Solr core for indexing to work correctly — search_api_solr provides a generated schema.xml (or, for newer Solr versions, a managed-schema config set) that needs to genuinely match what's on the Solr server. Mismatch this, and you'll see confusing indexing errors or silently wrong search results, not an obvious "not connected" failure.

Verifying it's actually working

# Search API's own status page shows connection health and index status.
# /admin/config/search/search-api
drush search-api:index  # Force a manual index run to test connectivity.

Quick check: after connecting Search API to Solr, indexing appears to succeed but search results seem incomplete or oddly ranked. What's a likely cause worth checking first? If you said a schema mismatch between what Search API Solr generated and what's actually deployed on the Solr server, you've identified the specific failure mode this lesson called out explicitly.

Key takeaways

  • Solr's inverted-index architecture is purpose-built for full-text search — a genuine architectural advantage over database-backed search, not just better tuning.
  • Solr runs as a separate service you provision alongside your web server and database, connected via the search_api_solr module.
  • The generated Solr schema must actually match what's deployed on your Solr core — a mismatch causes confusing, non-obvious failures.
  • Use Search API's own status page and drush search-api:index to verify the connection and indexing are genuinely working.

Coming up next

You've now got a faster search backend running. Last in this section: reducing what actually gets indexed, so even a fast backend has less work to do.