Your browser may have trouble rendering this page. See supported browsers for more information.

|<<>>|63 of 273 Show listMobile Mode

PostgreSql Drawbacks

Published by marco on

Despite the title, from what I can gather from 10 Things I Hate About PostgreSQL by Rick Branson (Medium), 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:

  • 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) vacuuming 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 copy 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.
  • 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,

    “I do understand their reasoning, which largely is about preventing users from attacking problems using query hints that should be fixed by writing proper queries. However, this philosophy seems brutally paternalistic when you’re watching a production database spiral into a full meltdown under a sudden and unexpected query plan shift. (Emphasis in original.)”