News for hackers. Stuff that matters.
Re:Thoughts on Uber’s List of Postgres Limitations by Dowwie on Wednesday August 03, 2016 @06:16AM (#12216908)
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?
Re:Thoughts on Uber’s List of Postgres Limitations by pwg on Wednesday August 03, 2016 @06:50AM (#12217051)
In one of the other HN threads on the issue, there was mention that the switch occurred shortly after a change in leadership position of individuals with enough 'power' to impart technology changes by decree. So there is an aspect that there was some, if not much, political opinion involved as there was any technical analysis involved in the change.

Given the fact that the change which occurred is an "apples to oranges comparison" change (PostgreSQL and an SQL normalized DB table structure to MySQL and a noSQL style single table key-value store) then there is some credence one can put towards the rumor that some (or most) of the change may have come about from a PHB [1] saying "do this, this way".

[1] PHB (Pointy Haired Boss, Dilbert cartoon reference)

Re:Thoughts on Uber’s List of Postgres Limitations by tehbeard on Wednesday August 03, 2016 @06:30AM (#12216973)
Most likely they don't have any engineers with the skills necessary to build/improve a RDBMS.

(note I said build, not use, different skillsets between driving a car and re-configuring the engine to run on seed oil)

Re:Thoughts on Uber’s List of Postgres Limitations by mhurron on Wednesday August 03, 2016 @08:24AM (#12217387)
> 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.

Re:Thoughts on Uber’s List of Postgres Limitations by mason55 on Wednesday August 03, 2016 @09:50AM (#12217859)
> 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/

Re:Thoughts on Uber’s List of Postgres Limitations by 0xmohit on Wednesday August 03, 2016 @02:27PM (#12220249)
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 by snaky on Wednesday August 03, 2016 @08:56PM (#12222654)
MySQL does need so much improvements

https://dom.as/2016/08/03/mysql-does-not-need-sql/

Re:Thoughts on Uber’s List of Postgres Limitations by amaks on Wednesday August 03, 2016 @07:40PM (#12222346)
Isn't MySQL owned by Oracle and closed sourced as a result these days?
Re:Thoughts on Uber’s List of Postgres Limitations by jasonlotito on Wednesday August 03, 2016 @09:29AM (#12217752)
Considering some of the things they wanted to improve were presented almost a decade before as problems (along with technically sound solutions to those problems), I actually think they did the best thing they could for the Postgres community.
Re:Thoughts on Uber’s List of Postgres Limitations by landmark3 on Wednesday August 03, 2016 @08:05AM (#12217317)
because they couldn't find what they were looking for in Posgres forum
Re:Thoughts on Uber’s List of Postgres Limitations by snaky on Wednesday August 03, 2016 @08:59PM (#12222664)
And we all know Uber cannot afford a couple of hours of professional PostgreSQL consulting.
Re:Thoughts on Uber’s List of Postgres Limitations by ssclafani on Wednesday August 03, 2016 @06:53AM (#12217055)
Re:Thoughts on Uber’s List of Postgres Limitations by okket on Wednesday August 03, 2016 @06:31AM (#12216977)
Re:Thoughts on Uber’s List of Postgres Limitations by merb on Wednesday August 03, 2016 @02:28PM (#12220259)
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.