Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Things I hate about PostgreSQL (2020)

rbranson.medium.com

Post reply on HN
Print view View original

41–50 of 255 posts

Re: Things I hate about PostgreSQL (2020)

#41

Post by why_Mr_Anderson »

I_am_tiberius wrote: post #26
theshrike79 wrote: post #19

Earlier quoted context omitted.

I think I've heard a saying about this, something about premature optimisation...

Sure you shouldn't care about scaling at the beginning. But why should you start using a system that you already know won't scale in the future?

But you have to get to that future first! If you lose your customers because you can't deliver something on time due to complexity of your 'scaling-proof' system or because you can't accommodate changes requested by clients because they would compromise your architecture, scaling will be last of your worries.

Re: Things I hate about PostgreSQL (2020)

#42

Post by jeltz »

oblio wrote: post #32

Maybe there are some core PostgreSQL hackers here: I know this probably sounds silly but for the transaction ID thing, it does seem like a big deal, is it really insurmountable to make it a 64 bit value? It would probably push this problem up to a level where only very, very few companies would ever hit it and from a (huge) distance the change shouldn't be a huge problem.

There have been several discussion about this and I if I recall correctly the main issue is that this would bloat the tuple size even more (PostgreSQL already has a large per-tuple overhead). The most promising proposal I have seen is to have 64-bit XIDs but only store the lower 32-bits per tuple but have a per-page epoch for the upper bits.

Re: Things I hate about PostgreSQL (2020)

#43

Post by yen223 »

marcus_holmes wrote: post #25
I_am_tiberius wrote: post #18

Earlier quoted context omitted.

The problem is that you want to build something that can scale in the future.

ffs, this attitude causes massively more problems than it solves. 1. You can always change later. Uber switched from Postgres to MySQL when they had already achieved massive scale. 2. You don't know what scaling problems you're going to get until you've scaled. 3. Systems designed to scale properly sacrifice other abilities in order to do that. You're actively hurting your velocity with this attitude. 4. Every single…

I am partial to the "don't solve problems you don't have" argument which holds true in a lot of cases.

That said, the database is the one part of the system that is very tricky to evolve after the fact. Data migrations are hard. It's worth investing a little bit of time upfront to get it right.

Re: Things I hate about PostgreSQL (2020)

#44

Post by theshrike79 »

I_am_tiberius wrote: post #26
theshrike79 wrote: post #19

Earlier quoted context omitted.

I think I've heard a saying about this, something about premature optimisation...

Sure you shouldn't care about scaling at the beginning. But why should you start using a system that you already know won't scale in the future?

Only if I _know_ I'm creating something that will definitely have huge amounts of concurrent users and someone pays me to make it scale from the start.

For a hobby project that might take off or might not, there's really no point in making everything "webscale"[0] just in case.

[0] https://youtu.be/b2F-DItXtZs

Re: Things I hate about PostgreSQL (2020)

#45

Post by nicoburns »

yen223 wrote: post #43
marcus_holmes wrote: post #25

Earlier quoted context omitted.

ffs, this attitude causes massively more problems than it solves. 1. You can always change later. Uber switched from Postgres to MySQL when they had already achieved massive scale. 2. You don't know what scaling problems you're going to get until you've scaled. 3. Systems designed to scale properly sacrifice other abilities in order to do that. You're actively hurting your velocity with this attitude. 4. Every single…

I am partial to the "don't solve problems you don't have" argument which holds true in a lot of cases. That said, the database is the one part of the system that is very tricky to evolve after the fact. Data migrations are hard. It's worth investing a little bit of time upfront to get it right.

> Data migrations are hard.

Yes, which is exactly why you shouldn't go with a highly scalable database solution. All of the solutions for really big scale involve storing data in non-normalised form, which mean the pain of data migrations frequently while developing features.

Best to avoid this until you have to.

Re: Things I hate about PostgreSQL (2020)

#46

Post by doctor_eval »

nicoburns wrote: post #45
yen223 wrote: post #43

Earlier quoted context omitted.

I am partial to the "don't solve problems you don't have" argument which holds true in a lot of cases. That said, the database is the one part of the system that is very tricky to evolve after the fact. Data migrations are hard. It's worth investing a little bit of time upfront to get it right.

> Data migrations are hard. Yes, which is exactly why you shouldn't go with a highly scalable database solution. All of the solutions for really big scale involve storing data in non-normalised form, which mean the pain of data migrations frequently while developing features. Best to avoid this until you have to.

Agree entirely. You're going to have to migrate anyway. May as well migrate from a database that's easy to work with.

Re: Things I hate about PostgreSQL (2020)

#47

Post by doctor_eval »

I_am_tiberius wrote: post #34
marcus_holmes wrote: post #25

Earlier quoted context omitted.

ffs, this attitude causes massively more problems than it solves. 1. You can always change later. Uber switched from Postgres to MySQL when they had already achieved massive scale. 2. You don't know what scaling problems you're going to get until you've scaled. 3. Systems designed to scale properly sacrifice other abilities in order to do that. You're actively hurting your velocity with this attitude. 4. Every single…

ffs, this attitude causes massively more problems than it solves. I don't think that it causes so many problems to just use MySQL instead of Postgres from the very beginning of a project. I like using Postgres and I understand that I shouldn't care about scaling but if a make a good decision from the very beginning it can't hurt.

Is MySQL a general solution to scaling? What if your scaling problem is with writes?

Re: Things I hate about PostgreSQL (2020)

#48

Post by doctor_eval »

I_am_tiberius wrote: post #40
oblio wrote: post #37

Earlier quoted context omitted.

What's that system? MySQL? Are there any other OSS RDBMSes which are comparable and scale better?

I would only have thought of MySQL.

MySQL isn't a general solution to problems of scale, because you don't know what problems you're going to have until you have them. So for example if your scaling problem is ACID compliant database updates - say you're the next fintech - then I was under the impression that MySQL would be the last database you'd want to be using. Have I missed something?

Re: Things I hate about PostgreSQL (2020)

#49

Post by chrisandchris »

I_am_tiberius wrote: post #34
marcus_holmes wrote: post #25

Earlier quoted context omitted.

ffs, this attitude causes massively more problems than it solves. 1. You can always change later. Uber switched from Postgres to MySQL when they had already achieved massive scale. 2. You don't know what scaling problems you're going to get until you've scaled. 3. Systems designed to scale properly sacrifice other abilities in order to do that. You're actively hurting your velocity with this attitude. 4. Every single…

ffs, this attitude causes massively more problems than it solves. I don't think that it causes so many problems to just use MySQL instead of Postgres from the very beginning of a project. I like using Postgres and I understand that I shouldn't care about scaling but if a make a good decision from the very beginning it can't hurt.

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.

Re: Things I hate about PostgreSQL (2020)

#50

Post by ksec »

>While much of this praise is certainly well-deserved, the lack of meaningful dissent left me a bit bothered.

Had the same feeling when I was reading that thread. And has been for quite some time when the hype is over the top.

The problem is seemingly Tech is often a cult. On HN, mentioning MySQL is better at certain things and hoping Postgres improve will draw out the Oracle haters and Postgres apologist. Or they are titled in Silicon valley as evangelist.

And I am reading through all the blog post from the author and this [1] caught my attention. Part of this is relevant to the discussion because AWS RDS solves most of those shortcomings. What I didn't realise, were the 78% premium over EC2.

[1] RDS Pricing Has More Than Doubled

https://rbranson.medium.com/rds-pricing-has-more-than-double...

Post reply on HN