An ElasticSearch Feature Comparison: Where Is the Beef?

November 15, 2012

There is an interesting but somewhat incomplete “feature comparison” between Solr and ElasticSearch. ElasticSearch, as you may know, is the new $10 million darling of the search world. Well, maybe Attivio with $42 million or Palantir with $150 million is “darlinger”?

You can find the write up at “Apache Solr vs ElasticSearch.” I want to point out that the comments to the basic information are quite useful. Among the points included in the comments which I found helpful were:

  • The notion of dynamic fields, field copying via multi-fields, and alternative query parsers
  • A reference to DataStax, Cassandra, and Solr
  • A suggestion that an eZ Publish reference be added.

However, I want to point out that in our analysis of ElasticSearch, there is one big factor not embraced by a feature list. Organizations want a system which is easy to install, maintain, and extend. Cost is a big deal, but when one factors in the costs associated with start up companies, there may be less predictability than with more established open source vendors such as Attivio, IBM, LucidWorks, and others.

As a side note, the publisher of the first three editions of the Enterprise Search Report, which I wrote, I had to produce nearly 20 feature charts. Guess what? Most of the feature charts were identical on the main points. The differences were of great technical importance to developers at the vendors’ firms. However, to the companies licensing software, the decisive factors were usually based on business considerations; for example:

  • Customer live demos and references from these customers
  • Pricing including support and training
  • Business stability
  • Engineering depth of the vendor
  • Financial performance over time
  • Management experience.

The fact that one vendor’s approach to k-means was “faster”, the metatagging system was “self learning”, or that another vendor’s system could index 10 gigabytes of content in X time slices was often irrelevant as decision time. Maybe open source search will be different, but right now, the open source world is on a vector that leads to the same business models which the traditional proprietary software vendors used with varying degrees of success?

In my view, a company in growth mode is juggling many balls at once and riding a unicycle. Consequently, the marketing and developer hyperbole may distract from the pure business considerations which garnered Attivio four times the funding that ElasticSearch obtained. The downside is that Attivio has to generate sufficient revenue to hit financial targets. Some financial types want five, 10, or 17 times the investment. I am too old and frail for that type of pressure. Even a $10 million cash infusion works out to $50, $170, or $100 million in revenues.

Only a handful of the 50 search vendors I track have revenues in shouting distance of $50 million. On a call with some MBA types last week, I learned that blowing past the revenues of Autonomy, Endeca, and Fast Search before their sale or implosion, was a “no brainer.”

I am not so sure. Building and sustaining revenue is more than a feature punch list. The real challenge is building and sustaining a business. Look at the present situation for HP Autonomy. Fast Search is, in my opinion, an end of life product. Endeca is an “all things to all people” solution. Endeca is darned good at eCommerce and processing certain types of data sets.

Open source software is important. Open source search is important too. What is more important is the constellation of factors that make “free” software into a viable commercial product which delivers a return to its funding sources. Will the open source community cheerlead when the VCs force the innovators who took those millions to produce a hefty profit? More than marketing and feature lists are needed. Just my opinion.

You can purchase the ElasticSearch analysis at this link for $3,500. Why so much? IDC has to generate revenue and return a profit. My hunch is that this is a fact of economic life that some open source code surfers do not yet hug and cuddle every hour or two.

Stephen E Arnold, November 14, 2012


4 Responses to “An ElasticSearch Feature Comparison: Where Is the Beef?”

  1. A. Steven Anderson on November 15th, 2012 8:59 am

    When it comes to open source solutions, companies providing support is a *nice to have* for many organizations looking to adopt the solution, whereas the prime objectives are off-the-shelf functionality, scalability, maintainability, and performance which is what ElasticSearch was engineered from the ground up to address.

  2. Andrei Filimonov on November 15th, 2012 12:04 pm

    I’m intrigued by you statement that FAST Search is an end of life product. Would you care to elaborate? Do you mean it as stand alone product? Do you see and future for FAST Search as part of SharePoint ecosystem?

  3. How to make keyword search in Endeca using presentation API? « Clean Java on November 16th, 2012 7:34 am

    […] An ElasticSearch Feature Comparison: Where Is the Beef? ( […]

  4. How to make a navigation query in Endeca using presentation API? « Clean Java on November 16th, 2012 7:48 am

    […] An ElasticSearch Feature Comparison: Where Is the Beef? ( […]

  • Archives

  • Recent Posts

  • Meta