Elastic search - Yes or No?

What problem are you trying to solve by moving to elastic search? Is there a problem with SQL search that is causing friction for your users?

There needs to be a clear gain from the switch in order to justify the time required to implement it.

In general, no.

Elastic Search clusters are notoriously difficult to deploy and maintain. When I let their parent company demo their paid cloud hosting to me, even they got it wrong on the first try.

In addition to that, there are many cases where Elastic Search can work, but where other simpler tools are superior in terms of performance, price, and maintenance work.

So unless you know that using Elastic Search is unavoidable, I would suggest to try other methods first. PostgreSQL's full-text search, for example, is excellent, fast, and pretty easy to setup. Plus, you can rent it from many established providers, e.g. Amazon RDS.

Hard to say without knowing more about your website and quantity of content you want to index.
ElasticSearch is based on Lucene which itself does not require much overhead. The size of the indexes and memory requirements based on your unique requirements might require a lot of overhead if you're want to index terrabytes of data.
In one web application, I ship ElasticSearch, well Lucene ,embedded into the app itself, i.e. so it starts when our app starts, and provides the users with a very functional search engine, indexing not only database entries but also word and pdf documents.

Perhaps you can share more details...

Elastic search requires good understanding and time-effort for performance tuning, which in my opinion is an overkill for small-medium websites or webapps.

Algolia[1] is a good hosted option. But if you're after a self-hosted option with great performance (robust and better than Elastic search), check out Manticore[2] Search (an open source fork of Sphinx[3] Search).

[1] https://www.algolia.com
[2] https://manticoresearch.com
[3] http://sphinxsearch.com

If you are trying to index content (posts, articles, etc.) on your site, go with Algolia. Elastic would be massive overkill.

Algolia is very lightweight, is purpose-built for the task, and will likely be a far better implementation (e.g. accurate) than a straight SQL search.

ElasticSearch is great... If you know all the knobs and levers you need to turn and pull to get the search results you want. I've wasted so much time on projects configuring ElasticSearch, and it wasn't ever something that interested me, which is probably why it took so long!

I found Algolia to be a great alternate. It's a SaaS search engine that's incredibly fast. I've webhooks configured to sync data to Algolia when my content changes in my CMS.

Algolia also has fantastic client libraries for React, Vue, etc. They provide a lot of the filtering, searching, facet filters out of the box!

PS. There are knobs and levers you can use if you want to be really specific but most often the defaults are good enough to get you going quickly.

I hope this helps :)

I setup an elastic search instance on AWS because of the speed and search capabilities as part of my mvp. I promptly shut it down after I got the first bill and decided to stick with plain SQL because it was good enough, was free, and didn't require any extra maintenance.

I think if your SQL search isn't performing well and you have a big database and want an in-depth search function and can afford all the costs associated with it then go for it. But if that's not the case then save yourself the trouble for now.