This page shows the source for this entry, with WebCore formatting language tags and attributes highlighted.
Despite the title, from what I can gather from <a href="https://medium.com/@rbranson/10-things-i-hate-about-postgresql-20dbab8c2791" author="Rick Branson" source="Medium">10 Things I Hate About PostgreSQL</a>, the author is a big fan of PostgreSql. However, he has such vast experience with it that he can still list 10 things that don't work as well as they could. They seem to boil down to: <ul> Default replication is still serialized and therefore not as reliable as the alternative async protocol that is much harder to configure and pretty much what every other major database offers. Obsolete-data-handling requires regular and fine-tuned (for performance-critical) <i>vacuuming</i> instead of just handling it in a cleaner manner like MySQL, Oracle or SQL Server (rollback log or temp tables) Indexes use more space than they should because they <i>copy</i> the indexed fields rather than referring directly to the data in the table. That is, unlike most other DBs, the index data is physically separate from the table data and therefore can nearly double the required space for a table with few columns. <div>The plan-builder doesn't support planning hints, which means you can't patch a query in production to buy time: you have to either meta-patch it (i.e. figure out some way of sending a "hint" to the planner through other means) or fix it for real, which can take a lot more time while your production servers are blowing up. From the article, <bq>I <i>do</i> understand their reasoning, which largely is about preventing users from attacking problems using query hints that should be fixed by writing proper queries. However, <b>this philosophy seems brutally paternalistic when you’re watching a production database spiral into a full meltdown</b> under a sudden and unexpected query plan shift. (Emphasis in original.)</bq></div></ul>