[grzm]

You make a lot of mention of "modern databases" without naming any. I specifically referenced the Jepsen project as it's repeatedly shown that many/most of the "modern databases"† (and those with more history) actually don't provide the features you describe without issue. Postgres is upfront about the current limitations rather than market itself as something it isn't. I'd ask to you be specific when calling out projects you prefer for your use cases so they may be actually compared. Handwaving serves no one well.

No system is the absolute best for every use case. No one is saying it is. But please be fair and lay all the cards on the table so we can all see and judge for ourselves.

† As an aside, this use of "modern database" sticks in my craw a bit. It's very imprecise. It seems you might be using it to mean anything non-relational or perhaps non-SQL. The so-called NoSQL database systems are often quite different even amongst themselves: lumping them together does a disservice to the individual implementations. Then again, perhaps I'm misinterpreting what you mean.

[b9b10eb736_]

I did not mention any database behind the very imprecise term "modern database" because it was not the point. Those databases at least try to solve those real-world issues in good or bad ways. Some people/companies have the empirical proof that they work for their use-case in production, just like I do, and I don't think the conversation is specifically about how good the DB solves the issue when Postgres does not even try to solve it. And again, I'm not saying this is bad (well, some of these points have become so essential nowadays in most of real-world applications that I think it's a very practical issue), but these are elements to take into account when opting for one DB or another. Sometimes, it may disqualify postgres, some other times it may not. In this respect, the original assertion (the one that made me react in the first place) “if PG gets better text search […] I don't see much reason to use anything else either.” just sounds very wrong to me. It depends on so much other (more important) things. At work, I have colleagues that are huge postgres fans to the point where they loose any critical sense on it. I think this situation is never ever good for engineers when it comes to taking the right decisions seriously.

I also know that distributed systems don't come without their own issues and complexity (CAP mostly, but also distributed systems = more complex = more bugs, and also younger = less mature = more bugs, and configuration issues, sharding issues). Some databases are very clear about those bugs and limitations (https://www.elastic.co/guide/en/elasticsearch/resiliency/cur...) some aren't (I don't think MongoDB documents them). Behind "modern databases", I am thinking of ElasticSearch, CouchDB (they solved a lot of issues regarding scalability recently by merging BigCouch in v2), MongoDB (arguably one of the worst way to address all the mentioned problems, but whatever), DynamoDB, for the databases I've been using or I'm currently using in production. I've also played around with AWS Aurora (yes, AWS is forking MySQL and Postgres to solve those issues at root which is a good proof that there is actually a demand), and also more specific databases like InfluxDB or key-value stores like Consul's. They all have their own solutions and tradeoffs. But I'm not sure mentioning them is very relevant for the argumentation.

[ecnahc515]

Honestly, the issue I have is I don't care if modern databases try to solve those problems, I only care if they _actually_ solve those problems, instead of them lying that they provide CAP and are distributed/infinitely scalable, when in fact, it isn't.