There's so many little things that add up that Just Work in terms of SQL usage under pg and are a pain under mysql.

A quick example is array types plus rowtypes (plus postgres having auto-group-by but -only- if you GROUP BY a pk, so it's predictable) letting you do something like this:

    SELECT author.*, json_agg(posts)
    FROM users author
    JOIN posts ON author.id = posts.author_id
    GROUP BY author.id;

and you'll get back a json array of the post row objects in your application so you get one-row-per-author-row in your query results but still fetch your 1-to-N relationship efficiently (I used JOIN rather than LEFT JOIN to get only people who'd actually authored a post, note, that was a choice rather than a typo).

Note, yes, there's no reason you can't get the same result without the json_agg and with a bit of code to collapse posts onto the right author as you page through the resultset, but the thing I'm trying to gesture at is that lots and lots of little quality of life improvements add up in a way you don't necessarily even notice that much until you've mostly only been working on pg projects for a couple of years and then try and do the now-seems-obvious thing in something else.

The people complaining about the steep operations learning curve aren't at all wrong though, lots of postgres tooling was written by people who assume you -want- to read the entire manual first and then configure things exactly how you want and even as that sort of person it still took me a while to get up to speed.

So ... maybe you shouldn't want to switch, but the above is why, overall, I usually don't find myself wanting to switch -from- postgres to something else.

(except when I realise we're literally just using the database as a key/value store with an SQL interface, because at that point, screw that, back as far as mysql 3.23 it was amazingly good at that and it's still fantastic at it so in that situation "don't be silly" applies)

While I like PG, I think this is such a specific use-case. And in general I've learned to avoid JSON columns in databases.

I was doing some large data aggregation using PG and I was pretty disappointed with its performance. I didn't think about trying MySQL...

In general, I agree, though pg's JSONB is effectiuvely hstore2 so its performance is surprisingly good.

This example didn't involve a JSON column in the database at all though, I was talking about turning native database rows into json data - so given tables like users(id, name) and posts(post_id, author_id, title, body) (apologies for pseudocodish rendering) instead of

    <author_id>, <author_name>, <post_id_1>, <post_title_1>, <post_body_1>,
    <author_id>, <author_name>, <post_id_2>, <post_title_2>, <post_body_2>,

you'd instead get

    <author_id>, <author_name>, json[
      { post_id: <post_id_1>, title: <post_title_1>, body: <post_body_1> },
      { post_id: <post_id_2>, title: <post_title_2>, body: <post_body_2> }
    ]

so on the application side you'd just deal with (for each row) something like

    let id = author.id;
    let name = author.name;
    let posts = author.posts;

and the 'posts' variable would be an array of objects with 'post_id', 'title' and 'body' keys.