In the world of search, there are often a few burning questions when it comes to considering the right technology for your organization.
One that we hear a lot is: Should we use Solr or Elasticsearch?
Here’s the scenario.
Your organization is looking for the right search engine to solve problems and increase business value so you immediately consider an open source solution, which will enable you to save money and avoid sacrificing critical features.
Unsurprisingly, Solr and Elasticsearch come to mind.
Both have evolved to become dominant players in the search engine market, surpassing other open source and commercial products, according to statistics from DB-Engines.
But selecting one over the other isn't easy.
A coin toss won’t do.
So what do you do? While there are other search options, let’s just put the two most popular open source search engines face-to-face and see how they differ.
Evaluating Apache Solr & Elasticsearch
1. Maturity and Community
Apache Solr has a longer history as it was created in 2004 and then contributed to Apache Software Foundation in 2006.
Elasticsearch is newer to the game, having been officially created in 2010. Since then, the creators of Kibana, Logstash and Beats have joined Elasticsearch to create the Elastic company and the Elastic Stack (its product family).
If you check GitHub, you can see both Solr and Elasticsearch have very popular open source projects with plenty of releases. They also have thorough documentation, including reference guides.
So overall, these two search engines have very active communities.
A very important detail, though, is that while both are released under the Apache license, and both are open source, they work a little differently.
Anyone can contribute features to Solr. However, with Elasticsearch, while people can still offer their contributions, only Elastic’s employees can review and accept them.
2. Vision and Core Technology
Both solutions have a clear vision and are making great strides in their visions.
Solr has been more oriented towards text search. Elasticsearch quickly carved out its niche in log analytics with its Elastic Stack (formerly known as the ELK Stack).
And while Elasticsearch and Solr are two different search engines, they were both built on Lucene.
Created in 1999 by one of the Hadoop creators (Doug Cutting), Lucene is the information retrieval software library under the hood of many search engines. It is extremely fast, stable, and probably is the most suitable technology to be at the heart of a search engine.
As a result, these search engines are widely used as the foundation of many leading search and big data platforms: Elasticsearch is part of Microsoft’s Azure Search and Solr has been integrated into Cloudera Search, for instance.
Based on my own experiences and what developers’ feedback I’ve heard, both Solr and Elasticsearch are solid, cost-effective platforms for a variety of search-based and analytics applications.
With proper architectures and configurations, performance won’t be much of an issue. In addition, since they both expose an API, it’s simple to index content from custom applications as well as standard, out-of-the-box applications.
When it comes to scalability, Elasticsearch seems to have an advantage over Solr. But there have been many improvements that can eventually close the gap between them.
You can visualize the data in Solr and Elasticsearch using completely custom dashboards or just tweaking the standard visualization features that come with each search engine.
What’s worth mentioning is that Solr has a strong on text search, seemingly becoming the standard for search applications.
Elasticsearch, with its analytics vision, has expanded beyond search to tackle log analytics and visualization using the combination of Elasticsearch, Logstash, and Kibana.
Solr comes with web administration bundled in, while Elasticsearch has multiple other premium plugins for security, alerting, and monitoring. This list showcases Elastic's entire product family.
So Come On: Solr or Elasticsearch?
This high-level view of Solr and Elasticsearch indicates that each search engine has its own strengths in serving enterprise needs and use cases.
The first step of your selection process should be to understand what application you have to build and what it is expected to achieve. Then, use these five criteria as a guideline to make your decision.
The right answer depends on your requirements, your budget, your timing and the complexity of your project. But the first step is to gather all the facts so you can make a thoughtful, reasoned decision.