I somewhat agree, and somewhat have the opposite view:
I love psql and tab completion, it's magic, in fact it spoiled me, I know have a hard time to work on any other DB.
Not mention in the article, but I love how the postgres dev keep up with modern SQL. Again it makes it really hard to go back on a SQL 92 compliant system.
Now, the vacuum business, that's horrible. I've run into so many case where "vacuum full" just solve the weirdest problems. One very recently where I use postgres as a queue (because it was easy and works across platform/clouds) nad it became slow and horrible even though I had dropped a bunch of schemas. "vacuum full;" oh wow!
The replications story is ugly. You can make it work, but it's literally a craft and you end up having to babysit it.
One the author missed, lots of weird performance issue, got my answer from the uber post. The rule #1 of adding indices is to only use column that you really really need, because otherwise you're going to slow down your writes. Well, it turns out not on postgres, all indices for the table you're writing to are being updated! I'm pretty sure very few people were aware of that before uber told us.
The more I use the postgres front end (psql, SQL) the more I love it, but the backend (performance, replication) is starting to taste more and more sour.
Really? Coming from PGSQL to a MySQL-only shop made me really miss PGSQL's performance. Sure, MySQL is faster on `select pk from tbl where pk=1`, but the second you get into complicated joins, including subqueries, or doing any analytics the performance is very random.
With pgsql, I can get a clear concise explain and if I disagree with what's happening (because I know exactly what my hardware is capable of) I can tune any query to be decently performant.
With mysql, you get... I mean explain is ok, but I wouldn't put it above that. "EXPLAIN ANALYZE" is my gold standard forever and ever. I even liked it more than SQL Server's equivalent; which is also fantastic.
In my experience, MySQL had the worst query optimizer of the three. By A LOT. Basically, anything but a simple select could suck very unnecessarily. Even for simple selects, MySQL messes up.
I've fixed more than performance issue by changing SELECT * FROM users WHERE key1 = 0 OR key2 = 5 into two queries and concatenating the results.
I suspect MySQL is used with more bare bones schemas, without as many SQL function and complex triggers, as it has worse support for those (IMO, as someone that used MySQL). This does have the side effect of making it very ORM friendly, and the more you rely on an ORM the less you care or even know what queries are being run under the covers.
I love psql and tab completion, it's magic, in fact it spoiled me, I know have a hard time to work on any other DB.
Not mention in the article, but I love how the postgres dev keep up with modern SQL. Again it makes it really hard to go back on a SQL 92 compliant system.
Now, the vacuum business, that's horrible. I've run into so many case where "vacuum full" just solve the weirdest problems. One very recently where I use postgres as a queue (because it was easy and works across platform/clouds) nad it became slow and horrible even though I had dropped a bunch of schemas. "vacuum full;" oh wow!
The replications story is ugly. You can make it work, but it's literally a craft and you end up having to babysit it.
One the author missed, lots of weird performance issue, got my answer from the uber post. The rule #1 of adding indices is to only use column that you really really need, because otherwise you're going to slow down your writes. Well, it turns out not on postgres, all indices for the table you're writing to are being updated! I'm pretty sure very few people were aware of that before uber told us.
The more I use the postgres front end (psql, SQL) the more I love it, but the backend (performance, replication) is starting to taste more and more sour.