Elastic Search consumes lots of memory. You have to provide the heap size a lot if you want the best out of it. The major problem is when a company wants to use Elastic Search but it is at a startup stage. At a startup stage, there is a lot of funds to consider. However, their use case is that they have to use a pretty significant amount of data. For that, it is very expensive. For example, if you take OLTP-based databases in the current scenario, such as ClickHouse or Iceberg, you can do it on 4GB RAM also. Elastic Search is for analytical records. You have to do the analytics on it. According to me, as far as I have seen, people will start moving from Elastic Search sooner or later. Why? Because it is expensive. Another thing is that there is an open source available for that, such as ClickHouse. Around 2014 and 2012, there was only one competitor at that time, which was Solr. But now, not only is Solr there, but you can take ClickHouse and you have Iceberg also. How are we going to compete with them? There is also a fork of Elastic Search that is OpenSearch. As far as I have seen in lots of articles I am reading, users are using it as the ELK stack for logs and analyzing logs. That is not the exact use case. It can do more than that if used correctly. But as it involves lots of cost, people are shifting from Elastic Search to other sources. When I am talking about pricing, it is not only the server pricing. It is the amount of memory it is using. The pricing is basically the heap Java, which is taking memory. That is the major problem happening here. If we have to run an MVP, a client comes to me and says, "Anurag, we need to do a proof of concept. Can we do it if I can pay a 4GB or 16GB expense?" How can I suggest to them that a minimum of 16GB is needed for Elastic Search so that your proof of concept will be proved? In that case, what I have to suggest from the beginning is to go with Cassandra or at the initial stage, go with PostgreSQL. The problem is the memory it is taking. That is the only thing.
