Skip to content Skip to footer

Insight

How to choose the right search platform for your Sitecore site

by Sam Mullins, Web Developer, 6 February 2019

Read Time: 7 minutes

In software engineering, the provider model is often used to ensure identical functionality regardless of the specific implementation chosen. Sitecore uses the provider model for its Content Search API, but each provider has its differences and you need to take care when deciding which one to use.

Sitecore provides three different search options that allow fast searching of content out of the box – Lucene, Solr, and Azure Search. Another option worth considering is Coveo, a proprietary enterprise search alternative that can be used via an extension of the Sitecore Content Search API.

Over the last year we’ve used all four of these options at Redweb and we’ve learnt that choosing the provider isn’t just a choice for the developer, it’s very important for the client to make the final decision. A Sitecore site must be built to last and due to the differences between the platforms, getting it wrong could result in costly and time-consuming changes. I’ll share my thoughts on where I’ve found each option to be most appropriate, which may help you make a more informed decision.

Lucene

The main benefit using Sitecore with Lucene is that it doesn’t require any extra configuration, and simply runs on the server on which Sitecore was installed. That’s why using Lucene is essentially free – as long as your hardware can handle the processing, you won’t have to pay a penny extra.

These factors make Lucene fantastic for local development or small instances such as demo sites.

As soon as you start to scale out, Lucene becomes less desirable and, on Platform as a Service (PaaS), it won’t work at all. As Lucene resides on the same hardware as the Sitecore site, you end up having multiple instances of the search index on load balanced setups. It can still work, but it is recommended to move to a centralised system such as Solr.

Sitecore 9 also throws another spanner in the works. If you use the XM configuration, you may be able to still use Lucene, but it’s not ideal. As soon as you switch to XP, Lucene is not supported. This is because xConnect cannot connect to a filesystem-based index such as Lucene.

I recommend choosing Lucene if:

You are on Sitecore 8.x or below, you don’t intend to upgrade, and you only have one server (and will never need more).

Solr

As the old saying goes, “Nobody ever got fired for buying IBM” and I feel the same can be said for Solr and Sitecore.

With Solr, you’re able to:

• use it with every modern version and configuration of Sitecore

• host Sitecore on premises and in the cloud

• enjoy it for free or pay for sophisticated enterprise level offerings

• use it with a single Sitecore server or many more

• harness powerful performance and reliability features such as sharding and clustering

Setting up Solr can occasionally be a little tricky as only certain versions of Solr are supported by each version of Sitecore, however there are now Solr as a Service offerings if you want to minimise effort on set-up and maintenance.

As Solr is based on Lucene, it is also fairly easy to upgrade from Lucene to Solr; this is a useful benefit if you’re migrating to version 9 and previously used Lucene, as you’ll end up with fewer regression issues.

I recommend choosing Solr if:

You don’t have a very strong reason to choose any of the other options; Solr should be your default choice.

Over the last year or so we’ve really started to appreciate Sitecore on Azure PaaS. Being able to scale, manage, and deploy with ease is a real eye opener. If you’ve decided to go all in on Azure to minimise infrastructural maintenance and centralise billing, Azure Search obviously has a very strong pull. Setup is incredibly simple, you just run the Sitecore Azure install script, and any scaling changes from then on can be done at the click of a button.

The problem comes with the provider implementation. The Sitecore Content Search API remains the same, but from our experience the queries generated are not always comparable to those on Lucene/Solr and some features are simply not available; we’ve had issues migrating an existing Lucene search for these reasons.

One feature that isn’t available is spatial search. Out of the box, the Azure Search provider shipped with Sitecore does not allow you search based on location. So, you’ll need to do extra work to enable it and it’s possible that you may stop querying through the Sitecore API altogether. Although arguably a simpler short-term fix, this will prevent you benefiting from subsequent Sitecore improvements and from switching providers easily in the future.

Azure Search is not based on Lucene and configuring Sitecore is therefore different. This becomes much more of an issue when you consider how the developers are going to work. The free version of Azure Search is limited to three indexes and in a clean install, Sitecore will already have more indexes than this so you will be forced to use the paid for plans.

Here lies the dilemma. Do you fork out on an Azure Search instance for each developer? Do you share an Azure Search instance between all the developers and risk clashes? Do you use Solr locally and rely on the Sitecore abstraction despite all the differences?

I find it hard to recommend Azure Search over Solr, but it may be worth stating that this assessment is based on the state of affairs in 2018. As Azure Search is used more this year, Sitecore and the community may find good ways to overcome the limitations; we have already received patches from Sitecore that fix some of the issues we have had.

I recommend choosing Azure Search if:

You are deploying your Sitecore site to Azure PaaS and you have determined that poor spatial search support and limitations with the API can easily be mitigated.

Coveo

Coveo Search is more than just an implementation of the Sitecore Content Search Provider. It provides a variety of pre-built components you can use on your site, backed by a very powerful enterprise search service with machine learning and personalisation abilities. This means you can provide a great search experience with very little development work, saving time and allowing a lot of flexibility. Of course, if required, developers can use the extended Content Search API to leverage the power of Coveo in ways not covered by the built-in components.

Coveo works equally well with Sitecore instances hosted on premises and in the cloud, and as the recommended approach is to use Coveo Cloud, setup is easy.

Despite being a very compelling choice, Coveo has a price tag and creating a business case for the increased cost may not be easy for some companies. The investment isn’t just financial, if you commit to using all the Coveo components it’s much harder to transition back to Solr or Azure Search than it would be switching between the other three options.

I recommend choosing Coveo if:

You have the budget to build or enhance a large site with all the features provided by a true market leading offering. Coveo is a product that could potentially provide a competitive advantage over rivals.

Making the right choice

This is only a brief outline of each of the four options, and realistically a deeper investigation should be made before deciding which option is best for your current (and next) project.

When making the choice, it’s important to consider your strategic aims for the next few years. What’s important to you and what technology does your business need to achieve your aims? Do you want to create a deeply personalised experience? Do you want to move to a PaaS infrastructure? Do you want to keep up-to-date with the latest versions of Sitecore?

You first need to ascertain your objectives, then choose your platform; doing these in the wrong order could result in a waste of time, effort, and money.

Sign up for insights

Be the first to receive thoughts from our industry experts and the latest Redweb updates

Thank you

By entering my details, I agree to the use and storage of my data as described in Redweb’s privacy policy.