While I&#x27;m happy to hear about a great success story of a great piece of open source software, Elasticsearch has done a great disservice by making application developers lazy about learning the ins and outs of various analytical&#x2F;transactional&#x2F;storage backend systems.<p>Echoing other commenters, Elasticsearch is hardly the best tool for many kinds of analytics. In fact, it is strictly not a good tool for several use cases. For starters:<p>1. It&#x27;s not good at joining two or more data sources<p>2. It&#x27;s not good at complex analytical processing like window functions (for example to calculating session length based on the deltas of consecutive timestamps partitioned by user_id and ordered by time).<p>Of course, it&#x27;s also good at many things like simple filtering and aggregation against &quot;real-time&quot; data. Being in-memory really helps with performance, and with right tools, it&#x27;s horizontally scalable. Elastic&#x27;s commercial support is also not to be discounted.<p>However, as an old OLAP fart who spent years optimizing KDB+ queries, I am deeply concerned about the willful ignorance of data processing systems that I see among Elasticsearch fans. Just take my word for it and study Postgres (with c_store extension) and other <i>real</i> databases, in-memory or otherwise, open-source or proprietary, so that you won&#x27;t be shooting yourself (or future co-workers) in the foot, trying to shoehorn Elasticsearch and its ilk into suboptimal workloads (To be fair, I see a similar tendency among Splunk zealots).