[taneem]

Postgres supports a sophisticated full text search featureset while mysql does not. Implementing full text search on Postgres is not that difficult and can prove to be a much cheaper alternative to Elastic Search up to a certain scale. This was a major reason for me to recently pick Postgres over any other storage technology.

[threeseed]

ElasticSearch is open source and free.

And nothing is stopping you running it on a single node like PostgreSQL. It's also better in every aspect as a search engine.

[arkh]

It is also: another server to handle, another view of your data you have to manage, another point of failure and another security entry-point.

If you don't need all the functionality of ES you can go a long way with the Postgres fulltext search. Once you scale enough or if search is your core business ditch it and deploy a better solution like Elastic Search.

[taneem]

Exactly. When getting started initially, it can be a huge time savings to get your basic full text experience running in Postgres directly, if that's already your main storage DB. Setting up ES is not at all trivial for the average developer and can waste a lot of precious time too early in a product's lifecycle.

[riku_iki]

Also ElasticSearch updates will not be in the same transactions as your DB data updates, which can create some mess.

[fusiongyro]

I have found Solr to be more reliable than ES and faster than Postgres for FTS. It is cool to be able to do it in-database though. Solr is a bit more work to configure than ES though.