Hacker News Reader

Yes we've used full text search for quite some time for one of our products, it's great, we really haven't had any issues performance or otherwise with it. For one of our other products we index data from PostgreSQL / PostGIS into elasticsearch and that's also good, in other ways.

View on HN

At a guess stemming from ignorance of Elasticsearch, I'm going to assume you'd join PostgreSQL and Elasticsearch like that in situations where you need to perform more complex analysis over the queries to provide results, is this correct? I've seen this particular architecture before and my biggest question was whether or not it was a piece that could be eliminated.

For, say, a tag-based search system (think any forum or booru-style imageboard), is Elasticsearch completely overkill?

I realise I could probably just google it™, but it's a lot easier to understand a product's strengths when they're put in a situational context.

Your guess is pretty much it: Postgres full text search is great for simpler scenarios, but elasticsearch provides more powerful search capabilities and simpler implementation of complex features (such as "search all shops in this geographical area with products that match these words the user typed".) That said, I've had good results with both systems, and always found the elasticsearch query syntax pretty arcane and difficult to put together from the docs. The docs essentially assume you are very familiar with Lucene concepts and that you'll be able to figure out what goes where in the JSON object from your past experience. If you are implementing a simple tag system, then I'd use Postgres first and only when performance becomes an issue move to elasticsearch.

Reply on news.ycombinator.com