Using Solr or Lucene

Last updated Tuesday, November 29, 2016 in Sitecore Experience Platform for Administrator, Developer

Sitecore supports both Lucene and Solr search engines. The search engines are used for searching in the content databases, as well as for searching in a number of operational databases that Sitecore uses for collecting analytics data, test data, and so forth.

The search engines that are used for these two different kinds of databases do not have to be the same instance of either Lucene or Solr, and they do not even have to both be either Lucene or Solr.

When visitors search for content, they use a search engine. Therefore, this search engine must be available from the Internet. On the other hand, the search engine that Sitecore uses for the operational databases does not have to be available from the Internet.

In most situations, you have a choice between using Solr or Lucene.


There is one situation where you cannot choose between search engines, but must use Solr. If the operational indexes are on a different server than the server that hosts the services and interfaces that access these indexes, you must always use Solr. All these services depend on search for the data they need. Solr supports calls over HTTP(S), whereas calls to a Lucene index must be made from the same machine that hosts the index itself.

The general reasons for using Solr instead of Lucene are:

  • When you need to index large numbers of items (50,000 and up), Solr performs better.
  • Solr is more robust. If your site depends on search as the primary interface, consider using Solr.
  • If you use multiple content delivery servers (or plan to do so later), use Solr. Solr works automatically in such an environment. You could use Lucene, but you have to make sure that indexes are synchronized across servers yourself.

    You should therefore use Solr if you plan to scale your site (have a distributed setup with multiple servers).

You can move from Lucene to Solr. The LINQ queries remain the same, but there are differences in configuration and so forth that you need to address. You will also have to rebuild indexes. The move is possible, but it is not a trivial task.

If you do move from Lucene to Solr, be aware that Lucene and Solr score search results in slightly different ways (which can look like there is something wrong unless you know this).

You can mix Lucene and Solr, and, for example, use Solr for xDB and Lucene for content search at the same time. If an index is small, it is much easier to manage as a Lucene index because there is little to no overhead to set it up.

In most cases, though, it is simpler to move everything to Solr once you need to use Solr for the operational databases.

Using Solr for scalability

Solr is also always required if you have a dedicated processing server and/or multiple content management servers. Content management servers use the Analytics index to search for contacts in the Experience Profile. To enable this, the content management server must have access to a search index. Lucene is a file based indexing system, which means if the index is not located on the server that the request is coming from you have to ensure that indexes across all servers remain in sync. Solr supports calls over HTTP(S) which means that the sitecore_analytics_index is available to all servers in the environment that require it (content management and processing servers).

It is technically possible to configure Lucene on a scaled environment by using file replication or UNC to synchronize indexes across all servers but we do not recommend this approach.


If you configure Solr use the 64-bit version of the Java Virtual Machine (JVM) for production servers. Solr allocates 512 MB of memory by default. If you require Solr to have access to more memory you can adjust these limits when Solr starts up. See the official Solr documentation for more information.