b9b10eb736_

Sorry if it was unclear. I think I explained preciely what I meant in my responses to grzm. I don't think there's any debate on the "poor resiliency" point for anybody that has already used a distributed database or even just used postgres in production and experienced a slave promotion. For the "Schemas remains at postgres core" thing, it's probably not as straightforward, but once again, I really think anybody who has ever used a document-driven database can understand what I mean through this. You really don't use postgres as you use a document-driven database because it's impractical. (More generally, this point could be completed with a list of all the features that are easy to handle in pretty much any non-19xx database and that are a nightmare in postgres (users, permissions, indices creations/deletion, …).)

threeseed has summed my thoughts up. Solar/ES are solving issues that postgres just don't address at all at the moment, and it's definitely not only about text search (which is also a point). Saying that postgres should be/can be used for any use-case apart from TS is an absolute nonsense and that's what made me react in the first place. Moreover, the feeling that the community don't largely agree just on the fact that postgres doesn't meet these four points is indeed a bit appalling. OK, saying that postgres should try to solve them is another debate, but let's just agree on the fact that if you absolutely need a very resilient OR distributed OR document-based OR easy-to-upgrade DBMS (although for this last point, I have to agree that things have changed recently, partly thanks to the Uber gate I think), postgresql is probably not a good choice. There's definitely a HUGE trade-off and we should agree on this. Postgres don't come even close to Solar/ES in term of horizontal scalability. I'd really like it could, but as of today it can't.

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.