Login

Imagine the use case:

1. A lot(100+) of small(10Mb-100Mb, 1000-100000 documents) search indexes.
2. They are using by a lot of applications (microservices)
3. Each application can use more than one index
4. Small by size index, yes. But huge load(hundreds search-requests per second) and requests are complex (multiple aggregations, conditions and so on)
5. Downtimes are not allowed
6. All of that is working years long, and constantly growing.

Idea to have individual ES instance per each index - is huge overhead in this case.

Based on my experience, this kind of use case is very complex to support with Elasticsearch.

Why?

FIRST.

The major problem is fundamental back compatibility disregard.

Breaking changes are so cool!
(Note: imagine SQL-server which require you to do small change in all your SQL-statements, when upgraded... can't imagine it. But for ES it's normal)

Deprecations which will dropped in next major release are so sexy!
(Note: you know, Java contain some deprecations, which 20+ years old, but still working in actual Java version...)

And not only that, sometimes you even have something which nowhere documented (personally came across only once but... )

So. If you want to upgrade ES (because you need new features for some app or you want to get bug fixes) - you are in hell. Especially if it is about major version upgrade.

Client API will not back compatible. Index settings will not back compatible.
And upgrade all app/services same moment with ES upgrade is not realistic.

But you must do it time to time. No other way.

Existing indexes is automatically upgraded? - Yes. But it not help you when you will need to change some old-index settings.

To live with that, you need constantly invest a lot of power in ... forward compatibility of you apps/services with future releases of ES.
Or you need to build(and anyway constantly support) some kind of middleware between you app/services and ES, which provide you back compatible client API.
(And, you can't use Transport Client (because it required jar upgrade for every minor version ES upgrade), and this fact do not make your life easier)

Is it looks simple & cheap? No, it's not. Far from it.
Continuous maintenance of complex infrastructure which based on ES, is way to expensive in all possible senses.

SECOND.
Simple API ? Well... no really.
When you is really using complex conditions and aggregations.... JSON-request with 5 nested levels is whatever, but not simple.

------------
Unfortunately, I have no experience with SOLR, can't say anything about it.

But Sphinxsearch is much better it this scenario, becasue of totally back compatible SphinxQL.

Note:
Sphinxsearch/Manticore are indeed interesting. It's not Lucine based, and as result seriously different. Contain several unique features from the box which ES do not have and crazy fast with small/middle size indexes.

## Update ##

Now that the question scope has been corrected, I might add something in this regard as well:

There are many comparisons between [Apache Solr][1] and [ElasticSearch][2] available, so I'll reference those I found most useful myself, i.e. covering the most important aspects:

* Bob Yoplait already linked kimchy's answer to [ElasticSearch, Sphinx, Lucene, Solr, Xapian. Which fits for which usage?][3], which summarizes the reasons why he _went ahead and created ElasticSearch_, which in his opinion _provides a much superior distributed model and ease of use_ in comparison to Solr.

* Ryan Sonnek's [Realtime Search: Solr vs Elasticsearch][4] provides an insightful analysis/comparison and explains why he switched from Solr to ElasticSeach, despite being a happy Solr user already - he summarizes this as follows:
> **Solr** may be the weapon of choice when building **standard search
> applications**, but **Elasticsearch** takes it to the next level with an
> **architecture for creating modern realtime search applications**.
> Percolation is an exciting and innovative feature that singlehandedly
> blows Solr right out of the water. **Elasticsearch is scalable, speedy
> and a dream to integrate with**. Adios Solr, it was nice knowing you. *[emphasis mine]*

* The Wikipedia article on ElasticSearch quotes a [comparison][5] from the reputed German iX magazine, listing advantages and disadvantages, which pretty much summarize what has been said above already:
> **Advantages**:
>
> * ElasticSearch is distributed. No separate project required. Replicas are near real-time too, which is called "Push replication".
> * ElasticSearch fully supports the near real-time search of Apache
> Lucene.
> * Handling multitenancy is not a special configuration, where
> with Solr a more advanced setup is necessary.
> * ElasticSearch introduces
> the concept of the Gateway, which makes full backups easier.
>
> **Disadvantages**:
>
> * <strike>Only one main developer</strike> *[not applicable anymore according to the current [elasticsearch GitHub organization][6], besides having a pretty active committer base in the first place]*
> * <strike>No autowarming feature</strike> *[not applicable anymore according to the new [Index Warmup API][7]]*

----
## Initial Answer ##

They are completely different technologies addressing completely different use cases, thus cannot be compared at all in any meaningful way:

* [Apache Solr][9] - _Apache Solr offers Lucene's capabilities in an easy to use, fast **search server** with additional features like faceting, scalability and much more_

* [Amazon ElastiCache][10] - _Amazon ElastiCache is a web service that makes it easy to deploy, operate, and scale an **in-memory cache** in the cloud._

* Please note that _Amazon ElastiCache is protocol-compliant with Memcached, a widely adopted memory object caching system, so code, applications, and popular tools that you use today with existing Memcached environments will work seamlessly with the service_ (see [Memcached][11] for details).

*[emphasis mine]*

Maybe this has been confused with the following two related technologies one way or another:

* [ElasticSearch][12] - _It is an Open Source (Apache 2), Distributed, RESTful, Search Engine built on top of Apache Lucene._

* [Amazon CloudSearch][13] - _Amazon CloudSearch is a fully-managed search service in the cloud that allows customers to easily integrate fast and highly scalable search functionality into their applications._

The _Solr_ and _ElasticSearch_ offerings sound strikingly similar at first sight, and both use the same backend search engine, namely [Apache Lucene][14].

While _Solr_ is older, quite versatile and mature and widely used accordingly, _ElasticSearch_ has been developed specifically to address _Solr_ shortcomings with scalability requirements in modern cloud environments, which are hard(er) to address with _Solr_.

As such it would probably be most useful to compare _ElasticSearch_ with the recently introduced _Amazon CloudSearch_ (see the introductory post [Start Searching in One Hour for Less Than $100 / Month][15]), because both claim to cover the same use cases in principle.

[1]: