Hacker News Reader

Comment by threesquared | Hacker News Reader

Why would you use Postgres for this which doesn't horizontally scale when you could easily index documents in ES and use that for full text search?

View on HN

If you only need modest search functionality and you don't want to manage another service/system, Postgres full-text search may be for you.

http://rachbelaid.com/postgres-full-text-search-is-good-enou...

I read this article about 6 years ago and after an afternoon I added full-text search to the app I worked on at the time. 6 years later, it's still the only search they use. This small tool already built into postgres has been more than enough for us.

I've had similar luck with sqlite, of all things. Unless it's envisioned to handle huge user loads, sqlite does a pretty amazing job of FTS, all contained in a tiny binary that runs when I want and only when I want. I find it very useful for finding nuggets in titles and descriptions, spanning across thousands or millions of records. the index is often double or even triple the size of the database, but its worth it for a query that returns in a heartbeat.

For static databases (especially where the content is not deleted, or rarely updated) consider using contentless tables or external content tables. The database size remains virtually the same, but you'll have immediate access to almost all FTS features.

I worked on a project where we needed to search in a set of approximately 2,5M addresses, and return the adresses' approximate coordinates. We already used postgres for our other database needs, so slotting this in in our existing stack took us all of a couple days.

Most projects will never scale horizontally.

Most projects will never *need* to scale horizontally.

Unfortunately, many will, due to FOMO and Resume Driven Development.

Good point :)

Reply on news.ycombinator.com