James did put a lot of thought into this post. I saw multiple iterations of it before it was published. I think calling it a shitpost is being unkind to him.
I think we just find that some developers don't like reading long posts, so he kept this one short :-)
But if you want something with more length/depth, here is another one we recently published:
I didn't want to go down that path for this article because I didn't want it to end up as a sales pitch. The article you describe needs to be written, but it's a follow-up in my mind (and much more technical, for a slightly different audience).
One of the biggest concerns about any DB is speed of query execution. Today a decent app/site can generate terabytes of machine data that you need to analyze. There is a massive difference in usability of a query that takes < 5 secs vs even 5 minutes. So, some benchmarks of speed vs major use cases would have been ideal.
I understand, general purpose DBs can't be the best, but I can compromise for 80%. If it's 50% or less, then I really have to question that choice.
But also, point taken. The article this comment thread describes also needs to be written.
(You could still use PostgreSQL, just not the same PostgreSQL servers that are running your user-facing features.)