True enterprise-class log-management solutions must have search technology that can reliably perform near real-time indexing at huge scale (over 200,000 events per second) while simultaneously handling high search volumes on the same index.

Our first-generation product used Solr because it was “months away” from being cloud-aware and supporting NRT (near real-time) search. When we reevaluated every component of our architecture in late 2012 ahead of building our second-generation service, we compared Solr to Elasticsearch. After spending a month with both products, Elasticsearch came out on top.

The technical factors we considered:

Search features (advantage: Solr)

Search scalability (advantage: Elasticsearch)

Plumbing (advantage: Elasticsearch)

Performance (advantage: Solr)

In the end, we viewed our decision for Elasticsearch as a fairly simple bet: That we’d spend less time on plumbing and more on our product.

We had a side bet that the areas of relative weakness in ElasticSearch would be addressed over time.

Both of those bets have paid off. Our Elasticsearch plumbing has been done at a higher level than the work we did with Solr. This allowed us to focus on our core product, which, after all, is what startups are supposed to do, and we turn those saved engineering cycles into customer-facing features.