Hacker News Reader

Having implemented this for a client in the past I have to agree that it is a cheaper option than ElasticSearch, especially for smaller projects with a lower number of records to index.

ElastiSearch easily gets expensive and the search suggestion is pretty bad.

View on HN

What does this mean ?

ElasticSearch starts off as a small Java application that wraps the Lucene library.

Obviously heap will increase with usage and number of documents but I am still confused how it is in any way "expensive".

The stack I proposed in my article is pretty simple: Django + PostgreSQL (DB + FTS).

In other project I used Elastic for the search function: Django + PostgreSQL (DB) + Haystack + ES (FTS).

Is obvious that the second solution is more expensive.

Thanks for your feedback, I obviously agree with you, but I'm starting to plan to use PG FTS with Django also in some bigger project. I hope to write another article about it in new future.

Depends on the data right. I've seen good performance on larger tables after using GIN indexing with records that rarely needs to be updated and simple queries. I'm not a expert in PostgreSQL by any means, but reducing cost and learning something never hurts.

I totally agree with you

Reply on news.ycombinator.com