As someone who has been using Elasticsearch since 2015 and currently working on a GraphQL python package for Elasticsearch, I advise people against using it until they have tried and exhausted all other options.

The effort alone to maintain, monitor, and scale is massive unless you have a big team. Ofcourse there are Google cloud and AWS implementation that provides scaling but it's crazily expensive.

One of the Opensearch clusters I have with AWS costs me approx $250 per month and it can barely handle 20gb of data with frequent read/write without seeing performance degradation.

Before this I had my own cluster which became too much to manage and the task of moving data from elasticsearch to Opensearch was a nightmare given how elasticsearch is not backward compatible.

So stay away from it until you have exhausted all the other solutions. It does work wonderfully when you do have to use it.

I manage a team which runs elastic clusters for customers.

> The effort alone [...] is massive unless you have a big team.

I'd like to put a different spin on that statement: operating a large production cluster requires a lot of expertise and probably a certification, but is apart from getting that experience not particularly time intensive thanks to elastic's excellent tooling.

> One of the Opensearch clusters I have with AWS

Our experience with elastic PaaS hasn't been that stellar either. We manage our own cloud clusters.

If you want the search that most people expect than yes. Postgres tsheadline for highlights doesn't respect phrase searches.

Postgres tsvector positional limitations of 16383 create a lot of false positives as well for phrase searching.