[gregmfoster]

To me, the critical points here are:

> PostgreSQL has a single master and multiple read replicas, Elasticsearch has horizontal scalability via sharding.

> if you have a large data set search and search relevancy is critical to your application (for example, in e-commerce), using a dedicated search engine like Elasticsearch is going to perform better

I love the mentality of "default to using Postgres for everything, and specialize when you need to." In this case, it looks like you'll need to evolve text search out of Postgres the moment your dataset gets into the millions, which roughly matches my experience.

[arcticfox]

Millions is way too low; we do extremely heavy FTS on Postgres in the millions magnitude and it is extremely effective. We also use a relatively tiny hosted box with tons of room for vertical scaling when we need to.

So I'm not sure at what point Postgres will start to be limited on this front but it's definitely a different order of magnitude, unless it's a wildly different workload than my team has.

[giovannibonetti]

It depends whether you're doing just FTS or also faceted search. In the latter case, you need a completely different kind of index (a covering index with all the filtered fields), and it'll be slow enough to be perceived by the user in the order of 1 million rows.

[mrelectric]

We have billions of records and fts still works on pg.

[tudorg]

That sounds interesting, are you using `ts_rank` or otherwise sorting by relevancy?