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

Thoughts on Uber’s List of Postgres Limitations

blog.2ndquadrant.com

Post reply on HN
Print view View original

81–90 of 108 posts

Re: Thoughts on Uber’s List of Postgres Limitations

#81

Post by simon2Q »

taspeotis wrote: post #11
grabcocque wrote: post #6

'Error establishing database connection' How very meta.

Fortunately they can call themselves! WHEN IT'S CRITICAL, YOU CAN COUNT ON US 2ndQuadrant provides full 24/7 problem resolution technical support for production systems. If PostgreSQL breaks, we'll get you back up quickly. [1] https://2ndquadrant.com/en/support/support-postgresql/

Which is exactly what happened and we fixed it fairly quickly, within the SLA we offer to customers. So I'm happy.

I accept all of the humour on that point with a grin myself, though I must say its a nice problem to have. Thanks to everybody for reading and commenting.

2ndQuadrant is a large enough company that we have CTOs who write blogs and design stuff, we have other people who run blog websites and a variety of infrastructure, but mainly we have many dev and support staff helping customers.

Re: Thoughts on Uber’s List of Postgres Limitations

#82

Post by aw3c2 »

bigato wrote: post #39
pilif wrote: post #22

Earlier quoted context omitted.

you can use pg_upgrade with -k - it will complete within seconds. Afterwards, things will be slow until a complete analyze updates the statistics, but the update itself can be done in seconds. I have updated ~2TB of database from 9.0 all the way to 9.5 over the years.

The problem with this is that if anything fails, you can potentially corrupt your data and have no backup plan. To make that option safe, you would have to copy your data directory first, and you need to be offline for that. So you have to add the time it takes to make that copy.

Solution: Have a backup plan.

;)

Re: Thoughts on Uber’s List of Postgres Limitations

#83

Post by simon2Q »

awalGarg wrote: post #33
grabcocque wrote: post #6

'Error establishing database connection' How very meta.

The site is powered by Wordpress, which, to the best of my knowledge, can work only with MySQL. Now that is very meta.

I believe the blog site does run MySQL. We eat our own dogfood wherever possible, especially on important services... we hadn't regarded the blog site in the same category until now.

Re: Thoughts on Uber’s List of Postgres Limitations

#84

Post by simon2Q »

f055 wrote: post #10

I came here to write a snarky comment, but now I can write two ;) first: if you think any particular db platform is clearly a winner in "db wars", you are naive. there are so many factors involved in configuring the db, the backend, the frontend etc. that you can always find a case where: the supposedly winning db is failing, or the supposedly worse db is performing perfectly fine. and from my experience, you should…

I agree that you should use the best tools for the current project. That is why we need to discuss which tool is the best and in what cases, which is all we've been doing here: providing the information people need to make reasonable comparisons.

There can be clear winners in such discussions, though this changes over the years. Many people are now concluding that Postgres is a winner at the present time and usage is expanding significantly. The people I meet aren't madly in love with Postgres, they make rational choices with the best information they have. Uber posted their information in the hope others would benefit. I think they have and I thank them for it.

(Whether you forgive me or not, I don't manage our blog site, but I guess they'll be some discussions. ;-) )

Re: Thoughts on Uber’s List of Postgres Limitations

#85

Post by hitekker »

f055 wrote: post #10

I came here to write a snarky comment, but now I can write two ;) first: if you think any particular db platform is clearly a winner in "db wars", you are naive. there are so many factors involved in configuring the db, the backend, the frontend etc. that you can always find a case where: the supposedly winning db is failing, or the supposedly worse db is performing perfectly fine. and from my experience, you should…

I sincerely dislike it when the mods change the positions of comments in a thread.

Re: Thoughts on Uber’s List of Postgres Limitations

#86

Post by im_down_w_otp »

mranney wrote: post #20
Illniyar wrote: post #7

I think its worth mentioning again that what Uber ended up using has no resemblence to an RDBMS (single table, manual indexes). So regardless of whether their complaints are justified or not, it should not be taken as an endorsment of mySQL over postgres, but rather of an endorsement of NoSQL over RDBMS . Which is really just what every company at these scales do (except for google and f5 if whitepapers are to be con…

Uber runs a lot of databases in production. We stopped using Postgres a while ago for new applications that talk SQL, and this article explains some of the reasoning. We still have many applications that talk directly to MySQL, and we still have our original API monolith that talks directly to Postgres. All new applications are being built using distributed databases like our in-house Schemaless system which happens…

I would love to see a similarly detailed write-up on your guys' transition from Riak to Cassandra. Especially considering you would have been really, really deep into the details and guts of operating Riak at the red-line from your time at Voxer.

Re: Thoughts on Uber’s List of Postgres Limitations

#87

Post by 0xmohit »

mason55 wrote: post #46
mhurron wrote: post #31

Earlier quoted context omitted.

> why didn't it try to improve Postgres Honestly, why would they? If there is a product that does what they need, why spend resources improving another. Just because it's open source and they could spend money improving it, doesn't mean a company will spend that money improving it.

> If there is a product that does what they need, why spend resources improving another. I would hardly say MySQL does what they need without any improvements. They built an entire second platform on top of it. https://eng.uber.com/schemaless-part-one/

MySQL does need improvements. This [0] is an example.

[0] https://github.com/facebook/mysql-5.6

Re: Thoughts on Uber’s List of Postgres Limitations

#88

Post by merb »

okket wrote: post #13
Dowwie wrote: post #8

Does anyone know the back story to Uber - why didn't it try to improve Postgres rather than move on to feed on another host?

Watch https://vimeo.com/145842299

actually I watched the video and the errors happend here are more cultural errors. I guess the switch is more like a "we failed, so we start new". and new means with something different.

also their replication strategy looked like a joke and not enough automation. hopefully they never use galera, else their bad engeering practices could actually suffer in huge data losses.

I've once run galera-cluster and it pretty easy came to data losses especially after short network splits which occured randomly at the network.

Post reply on HN