I'm curious if we will see similar improvements for full-text search. If PostgreSQL continues to improve at this rate, there will be little reason to use many of alternatives...

Personally, I already view PostgreSQL comparable (for many use cases) to paid options[1].

Interesting, for queries such as:

   EXPLAIN ANALYZE SELECT * FROM (SELECT * FROM sort1 ORDER BY 1) AS a LIMIT 5 ;
You'll see an order of magnitude speed improvement (page 47 of [2]).

[1] https://austingwalters.com/fast-full-text-search-in-postgres...

[2] https://h50146.www5.hpe.com/products/software/oe/linux/mains...

Seriously if PG gets better text search to put it on par with Lucene (Rum indexes, BM25 and TF*IDF) I don't see much reason to use anything else either.

From the top of my head, I can list at least four reasons to actually use anything else:

- Not distributable

- Poor resiliency

- Hard to upgrade

- Schemas remains at postgres core

Every solution to address any of these points in PG are hacks (bucardo, londist, slony, pgbouncer, things relying on triggers or proxies). Quite honestly, PG contributors are doing an impressive job. PG is arguably the best relational database in the market as of today and still improving very fast. However it's also one of the most (if not the most) bloated. And despite all these features nobody needs and after all these years, it's still lacking some very basic yet essential items anyone would ask for in any modern application. It feels like things haven't changed that much since the 90's. DBAs have to hack around things and root issues never gets addressed. Implementing JIT optimizations looks like fun. It will undoubtedly improve some queries by 2x, 4x or even 10x, but it won't be a game changer anyways. It'll just increase the postgres bloat and the overall complexity of the system. Meanwhile, we'll still be lacking essential things that would make PG suitable for pretty much any use-case.

Shame comments like this get downvoted. Because it's 100% true.

PostgreSQL still is lacking with its horizontal scalability story and there is no reason to choose it over something like Solr/ElasticSearch right now largely because of this.

You're the reason why I inherit project that uses only ES and then end up doing relational schema in ES because they didn't use relational database in general.

If you had to choose between PostgreSQL or ElasticSearch then you have no idea what you're doing.

https://github.com/zombodb/zombodb works for me by turning Elasticsearch into an index type (PG10 only)