1. Can't define variables as easily as in SQL.
2. Weak support for functions/SPs as a result.
3. Naming conventions inconsistent with SQL which makes any ORMs a pain.
Things I hate about PostgreSQL (2020)
101–110 of 255 posts
Re: Things I hate about PostgreSQL (2020)
#102I think it’s worth mentioning that most of these problems only occur at a scale that only top 1% of companies will reach. I’ve been using PostgreSQL for over a decade without reaching any of the mentioned scaling-related problems. PostgreSQL is still the best general purpose database in my opinion, and you can then consider using something else for parts of your application if you have special needs. I’ve used Cassan…
Not true - I work at a company of 400 people, and we ran into the Process-Per-Connection / pgbouncer issue.
I guess that’s very dependent of what kind of framework you’re using. The only PostgreSQL-driver I’ve seen that does not have connection pooling built-in is the PHP one (since PHP’s runtime model does not work in a way where that would be easily possible).
Re: Things I hate about PostgreSQL (2020)
#103I think this is a good list, one needs to know potential pitfalls and plan accordingly. As for point #7, if your upgrade requires hours, you are holding it wrong, try pg_upgrade --link: https://www.endpoint.com/blog/2015/07/01/how-fast-is-pgupgra... (as usual, before letting pg_upgrade mess with on disk data, make proper backups with pg_basebackup based tools such as barman).
my only complaint with the pg_upgrade (with or without the --link) is for some reason, it does not move the statistics over, and you have to rebuild them, or have horrible performance for a while, until each page hits it auto-analyze thresholds.
I'm doing some testing now for my DB, and the rebuilding all stats takes far, far longer than the upgrade. The upgrade takes seconds, and it takes a while to analyze multi-TB sized tables, even on SSDs.
Re: Things I hate about PostgreSQL (2020)
#104Earlier quoted context omitted.
I would rather use Postgres and have a RDBMS that is quite strict and migrate data later instead of having a RDBMS that just does what it likes sometimes. For example, query your table „picture“ with a first column „uuid“ (varchar) with the following query: SELECT * FROM picture WHERE uuid = 123; I don‘t know what you expect, I expect the query to fail because a number is not a string. MySQL thinks otherwise.
In Oracle it will fail, but only if uuid has characters that can't be parsed as numbers...
Does that make it better? IMHO, it‘s even worse.
Re: Things I hate about PostgreSQL (2020)
#105Only thing I really hate about PostgreSQL (probably not specific to it) is the lack of visibility into triggers. Give me jaeger style tracing for each trigger with per statement durations and I would be a very happy dev.
Your statement intrigued me, so I fired up the ol' googles and started looking to see if anyone had tried this. And within the first page of results I found a comment from you a few months ago saying the same thing! :)
This seems really interesting - at least for debugging (I worry that it would tank performance under load). Have you considered trying to work on it? My googling suggest that you seem rather interested in the idea! The postgres community is overall really welcoming to contributions (as is the OpenTelemetry community, hint hint).
Re: Things I hate about PostgreSQL (2020)
#106Another recent Postgres-complaint post from one of the best engineers I've worked with: https://blog.nelhage.com/post/some-opinionated-sql-takes/ Quoting his conclusion: > 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 s…
As long as mysql can't run ddl statements in a transaction it's worthless as far as I'm concerned.
Also the thing where they (used to?) silently truncate your data when it wouldn't fit a column is absolutely insane. I'll take operational footguns over losing half my data every damn time.
Re: Things I hate about PostgreSQL (2020)
#107Postgres still doesn't support native global replication, :( this is kind of a deal breaker for me.
Re: Things I hate about PostgreSQL (2020)
#108One thing I hate about such articles is this "((use)) a managed database service" hint. Many if not most readers' data are confidential and storing them on a machine managed by unknown people seems foolish to me. Am I paranoid?
> Am I paranoid?
Yes, because letting someone who knows what they are doing run your database is in most cases a better idea / more secure than doing it yourself if that's not your main business. If you pick a reputable provider there's not really an incentive for them to not keep your data confidential.
Example: All the open MongoDB instances because the owners expose them to the internet with a simple configuration mistakes.
Re: Things I hate about PostgreSQL (2020)
#109One thing I hate about such articles is this "((use)) a managed database service" hint. Many if not most readers' data are confidential and storing them on a machine managed by unknown people seems foolish to me. Am I paranoid?
Yes, but no.
I'm a staunch believer that multi-tenant hardware and managed services are _obvious_ no-gos for privacy reasons.
But, having done B2B where i had to deal with security procedures/questionnaires/documentation/checklists from large customers, no one else agrees.
Re: Things I hate about PostgreSQL (2020)
#110For the ones who know: is MySQL (without Percona) affected by the same issues the author is talking about?