Things I hate about PostgreSQL (2020)
Another recent Postgres-complaint post from one of the best engineers I&#x27;ve worked with: <a href="https:&#x2F;&#x2F;blog.nelhage.com&#x2F;post&#x2F;some-opinionated-sql-takes&#x2F;" rel="nofollow">https:&#x2F;&#x2F;blog.nelhage.com&#x2F;post&#x2F;some-opinionated-sql-takes&#x2F;</a><p>Quoting his conclusion:<p>&gt; As for Postgres, I have enormous respect for it and its engineering and capabilities, but, for me, it’s just too damn operationally scary. In my experience it’s much worse than MySQL for operational footguns and performance cliffs, where using it slightly wrong can utterly tank your performance or availability. … Postgres is a fine choice, especially if you already have expertise using it on your team, but I’ve personally been burned too many times.<p>He wrote that shortly after chasing down a gnarly bug caused by an obscure Django&#x2F;Postgres crossover: <a href="https:&#x2F;&#x2F;buttondown.email&#x2F;nelhage&#x2F;archive&#x2F;22ab771c-25b4-4cd9-b316-31a86f737acc" rel="nofollow">https:&#x2F;&#x2F;buttondown.email&#x2F;nelhage&#x2F;archive&#x2F;22ab771c-25b4-4cd9-...</a><p>Personally, I&#x27;d still opt for Postgres every time – the featureset is incredible, and while it may have scary footguns, it&#x27;s better to have footguns than bugs – at least you can do something about them.<p>Still, I absolutely wish the official Postgres docs did a better job outlining How Things Can Go Wrong, both in general and on the docs page for each given feature.