Live data from Hacker News

Things I hate about PostgreSQL (2020)

rbranson.medium.com

181–190 of 255 posts

Re: Things I hate about PostgreSQL (2020)

#181
post #106
post #82

Another 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.

Till v8.0.16 mysql used to accept and then just ignore check constraints

I've never been so offended by a technology as the day I discovered that; it's not a misfeature and its not a bug -- only pure malice could have driven such a decision

Re: Things I hate about PostgreSQL (2020)

#182
post #78

My only complain about PostgreSQL is COUNT() being quite slow compared with MySQL. Everything else is pretty good, MySQL has compressed tables, but in PostgreSQL the same amount of data already takes less space by default. Pghero/pg_stat_statements are also very handy. But "hate"? No, no hate here :)

just so you're aware, COUNT() on mysql can lie. Basically it's fetching metadata on the table, which can in some cases not be updated (yet), where as in pg it actually counts entries in the index.

Does it really count entries in the index? For example, in Firebird, it has to fetch rows because of row versioning (which happens in data pages, not in indices), and since PostgreSQL does versioning, too, I would have assumed that it's subject to the same limitation if it wants to return a correct answer for the current transaction.

Re: Things I hate about PostgreSQL (2020)

#183

Earlier quoted context omitted.

Renaming would be even worse!

Seems to me that they could safely rename to Postgres without much downside.

Among other potential issues, this would make it much harder to search for information related to the database. Starting out, it'd always make sense to google for eg "postgres ilike", but for new features you'd have to search for eg "NewNameSQL kindalike" (assuming a new ILIKE replacement called KINDALIKE comes along in pg15 aka newname3).

Even years in to the rename, newcomers to NewNameSQL would need to be told that it used to be called Postgres and that they should look for things related to that too.

Tools and code that refer to Postgres would all have to change their names, including those developed internally, open-source, closed-source, and no-longer-maintained. Not all would, and some would change the name and functionality at the same time.

It'd be chaos.

Re: Things I hate about PostgreSQL (2020)

#184
post #5

Earlier quoted context omitted.

Funfact: PQ is short for toilet paper in French So libpq always cracks me up. But then again there's a theorem prover called Coq (which is indeed pronounced as you imagine, it means rooster) and it's been named by French researchers at INRIA!

As an American, I feel like I have to deliberately mis-pronounce 'coq' the theorem prover like 'coke' the soda.

Same. It really doesn't help that their logo is skin-colored and the shape that it is...

Re: Things I hate about PostgreSQL (2020)

#187
post #8

I 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…

Everytime I see comments that praises PostgreSQL on top of MySQL without any explanations, I tend to think they're trying to bury a product from Oracle than from a real need of one over the other.

Re: Things I hate about PostgreSQL (2020)

#188
post #84

Earlier quoted context omitted.

I have not seen comments about technical debt. I think you are right: It is good to take shortcuts to ship faster. When you do that, you accumulate technical debt. I think it is important to identify it and to remain aware of this debt. I've seen too many people in denial who resist change.

It's not even tech debt. It's like a "tech short" - assuming you'll have this specific scaling problem in the future, and paying the cost now.

"Tech short" - I love it. I'm going to use that.

Re: Things I hate about PostgreSQL (2020)

#189
post #82

Another 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…

Does anyone know of a quality, comprehensive book that enumerates all the things to watch out for and problems to proactively prevent when operating Postgres at scale?

It's not a book, but Christophe Pettus' blog (https://thebuild.com/blog) has a lot of really good information. In particular, his talk "Breaking PostgreSQL at Scale" goes through the problems you run into as you hit different levels of scale (https://thebuild.com/presentations/2019-fosdem-broken.pdf)

Re: Things I hate about PostgreSQL (2020)

#190
post #8

I 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…

Everytime I see comments that praises PostgreSQL on top of MySQL without any explanations, I tend to think they're trying to bury a product from Oracle than from a real need of one over the other.

Maybe some younger developers, but I'd imagine a lot of us grew to dislike MySQL years before Oracle bought it (in 2010). I'd switched to Postgres already by then.
Post reply on HN