A Drupal site with a few thousand pages rarely thinks about scale. One with hundreds of thousands of nodes, a decade of revisions, tens of thousands of documents, and dozens of department sites thinks about little else. Search slows, admin listings time out, and backups take hours. None of this means Drupal has reached its limit. It means the site has outgrown its defaults. Search is usually the first thing to fix, and the rest follows a familiar pattern.
How Drupal search is built
Serious Drupal search runs on the Search API module. Search API separates what gets indexed (content types, fields, files) from where the index lives (a backend). That means you can move from database search to Solr or OpenSearch without rebuilding your search pages, facets, or views. It also means index design is a configuration decision you can review and version like any other.
Choosing a backend
| Backend | Strengths | Good fit when |
|---|---|---|
| Solr | Long, mature Drupal integration; strong relevance tuning; common in higher education and government | You already run Solr, or are moving from a platform that provided it |
| OpenSearch | Open source, available as a managed AWS service, strong performance and analytics | You want a managed service on AWS and room to grow |
| Elasticsearch | Feature-rich, widely used | Your organization already standardizes on it |
All three deliver fast, relevant search at scale. The better choice usually depends on what your organization already operates and where you host, more than on features.
Searching across sites and documents
- Federated search across multi-site. Several Drupal sites can write to one shared index, each tagged with its site, so residents search everything from any site and can filter by department.
- Document contents. With a text-extraction service in the pipeline, the contents of PDFs and Office files are indexed alongside pages. For many government and university sites, documents are what people are actually looking for.
- Facets for content type, department, date, and topic turn a long result list into something people can narrow quickly.
Indexing at scale
New and changed content should be indexed within moments of saving, through a queue processed by cron or a dedicated worker. Full reindexes, needed after schema changes, can take hours on large sites. They should run in the background, in batches, while the existing index keeps serving searches, rather than wiping the index first. Monitor the indexing queue: if it keeps growing, new content is not appearing in search.
Keeping large sites fast beyond search
| Growth area | What to do |
|---|---|
| Revisions | Keep a sensible number per node; the Node Revision Delete module can prune old ones on a schedule |
| Admin content listings | Use indexed filters and paging; move complex admin searches to Search API |
| Views | Cache them, avoid unindexed sorts and filters, and paginate |
| Log and cache tables | Send logs to syslog and caches to Redis or Memcached rather than the database |
| Files and media | Store on shared or object storage behind the CDN; clean up unused files |
| Database size | Right-size the database, add read replicas for read-heavy load, and test restores so backup time stays acceptable |
Relevance is an ongoing job
Search logs show what people want. Review the top queries and the zero-result queries every quarter. Add synonyms for the words residents use, boost service pages above news, demote archived content, and pin best results for high-volume searches. Relevance tuning is content work as much as technical work, and it pays off in fewer phone calls asking where things are.
Scale work is easiest when it is routine. A quarterly look at table sizes, revision counts, index health, and the slowest pages catches growth problems while they are still small, rather than when an editor reports that the admin screen has stopped loading.
How eWay runs Drupal search at scale
eWay operates enterprise search for Drupal on OpenSearch, Solr, or Elasticsearch, chosen to fit your environment. eWay designs the index around your content model, sets up real-time indexing and document extraction, builds federated search for multi-site platforms, and runs reindexes without taking search offline. Index freshness, indexing failures, and query latency are monitored continuously, and eWay tunes the database, caching, and storage layers so the whole site stays fast as content grows.
What to include in a support ticket
- The severity you would assign, P1 to P4 (see severity levels and response times)
- Example searches with poor results, or content missing from search
- Which sites or content types are affected
- For performance: the slow pages or admin screens and roughly how slow
eWay customers can open a ticket in the support portal or email support@ewaycorp.com at any time. See how to request support for all the options. Related reading: high-speed on-site search with OpenSearch and running multi-site Drupal for many departments. More on our Drupal page.
Was this article helpful?
That’s Great!
Thank you for your feedback
Sorry! We couldn't be helpful
Thank you for your feedback
Feedback sent
We appreciate your effort and will try to fix the article