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

Why Uber Engineering Switched from Postgres to MySQL (2016)

eng.uber.com

Post reply on HN
Print view View original

21–30 of 133 posts

Re: Why Uber Engineering Switched from Postgres to MySQL (2016)

#21

Post by throwdbaaway »

glogla wrote: post #16
frankietaylr wrote: post #10

Has Postgres architecture changed since Postgres 9.2 in terms of the inefficiencies mentioned in the article?

Sure, but it does not really matter. Uber has not switched from Postgres used as RDBMS to MySQL used as RDBMS , they switched from Postgres used as RDBMS to MySQL used as key-value storage layer of homegrown sharded non-relational database . This has pretty much no bearing on anyone using Postgres or MySQL in reasonable way.

Exactly. I think the prior HN discussions failed to call out how painful it is to do any sort of schema migration against a big InnoDB table [1][2].

Well known MySQL uses such as Facebook TAO and this Uber Schemaless are typically abstractions built on top of MySQL, which means the schemas are pretty much static, and they don't feel the schema migration pain.

For a typical RoR startup that relies on a RDBMS, please, stay away from MySQL.

[1] Yes, I know about the INSTANT ADD COLUMN patch from Tencent Games that landed in MySQL 8.0, and which has had major bug fixes in at least 8.0.14 and 8.0.20.

[2] A side effect is that MySQL now has a thriving ecosystem of schema migration tools (pt-osc, lhm, gh-ost), while Postgres has none, and there are situations where there is indeed no choice but to rewrite the table, e.g. changing a column type from int to bigint.

Re: Why Uber Engineering Switched from Postgres to MySQL (2016)

#22

Post by tinus_hn »

eznzt wrote: post #7
DaiPlusPlus wrote: post #3

Earlier quoted context omitted.

Define: "complicated"

Just creating a new user is annoying enough. Permissions are also much more complex. What the hell are schemas?

It would be great if there was some management GUI for these tasks so you don’t have to look up the syntax for these things that in many deployments you only do once.

Re: Why Uber Engineering Switched from Postgres to MySQL (2016)

#23

Post by desas »

eznzt wrote: post #20
oftenwrong wrote: post #13

Earlier quoted context omitted.

Schemas are similar to databases in mysql. They serve as a namespace. In mysql you can have a database `foo` and a table `foo.bar`. In postgres you can have a schema `foo` and a table `foo.bar`. In postgres you can have multiple databases in a cluster, and multiple schemas within each of those databases.

What you are basically saying is that yes, they are much more complex.

It's another layer, you don't have to use it. If you pretend schemas don't exist you basically never know they do, unless you go looking for complexity in the postgres bowels.

Re: Why Uber Engineering Switched from Postgres to MySQL (2016)

#24

Post by martimarkov »

corty wrote: post #8
DaiPlusPlus wrote: post #3

Earlier quoted context omitted.

Define: "complicated"

PostgreSQL: "your date 2020-02-31 isn't a date, fix that" MySQL: "2020-02-31? Whatever man, I'll just enter something..."

Oh yeah old complication of sanitising input...

It’s like asking you for an int and you entering 2.358 and saying that’s just simple.

Re: Why Uber Engineering Switched from Postgres to MySQL (2016)

#26

Post by user5994461 »

frankietaylr wrote: post #10

Has Postgres architecture changed since Postgres 9.2 in terms of the inefficiencies mentioned in the article?

The replication was redone around that time (not sure which version exactly). It's still working on the same principles though, sending queries and redoing them on each replica.

Before in short, the WAL was sent every minute and always 10MB even if there were no changes. Now it's more adaptive, actually doing nothing when they are no changes, and picking up quicker when changes begin.

I am surprised they don't mention this point because the replication was really unusable in PostgreSQL.

There are still spikes (write amplification) and other drawback from this design, but at least it doesn't shit itself under no activity.

Re: Why Uber Engineering Switched from Postgres to MySQL (2016)

#27

Post by rleigh »

eznzt wrote: post #20
oftenwrong wrote: post #13

Earlier quoted context omitted.

Schemas are similar to databases in mysql. They serve as a namespace. In mysql you can have a database `foo` and a table `foo.bar`. In postgres you can have a schema `foo` and a table `foo.bar`. In postgres you can have multiple databases in a cluster, and multiple schemas within each of those databases.

What you are basically saying is that yes, they are much more complex.

They are not complex, and they are entirely optional. They are just a namespace. You are free to never, ever use them.

For a company the size of Uber, I don't think spending five minutes reading the documentation for createuser is a significant burden to deployment. PostgreSQL is very easy to deploy.

Re: Why Uber Engineering Switched from Postgres to MySQL (2016)

#28

Post by alberth »

glogla wrote: post #16
frankietaylr wrote: post #10

Has Postgres architecture changed since Postgres 9.2 in terms of the inefficiencies mentioned in the article?

Sure, but it does not really matter. Uber has not switched from Postgres used as RDBMS to MySQL used as RDBMS , they switched from Postgres used as RDBMS to MySQL used as key-value storage layer of homegrown sharded non-relational database . This has pretty much no bearing on anyone using Postgres or MySQL in reasonable way.

What about Postgres native key-store called HStore?

https://www.postgresql.org/docs/8.3/hstore.html

I love Postgres just as much as anyone but Uber use case still seemed to be a better fit for MySQL. I was hopeful this would kickstart a renewed focus on features / architecture within thr Postgres community and I’m not certain anything resulted from this. Hope to be wrong obviously.

Re: Why Uber Engineering Switched from Postgres to MySQL (2016)

#29

Post by bombcar »

blowski wrote: post #19

I spent a whole decade saying "Why do I need Postgres? MySQL is fine." Started using Postgres a couple of years ago, and I now can't believe I ever lived without window functions, native arrays, custom types, etc.

I’ve wanted to try post geese but have never really had a chance - everything I do is “prepackaged” and things like Wordpress or Confluence really don’t seem to care if it is MySQL or Postgres.

Re: Why Uber Engineering Switched from Postgres to MySQL (2016)

#30

Post by Quekid5 »

user5994461 wrote: post #26
frankietaylr wrote: post #10

Has Postgres architecture changed since Postgres 9.2 in terms of the inefficiencies mentioned in the article?

The replication was redone around that time (not sure which version exactly). It's still working on the same principles though, sending queries and redoing them on each replica. Before in short, the WAL was sent every minute and always 10MB even if there were no changes. Now it's more adaptive, actually doing nothing when they are no changes, and picking up quicker when changes begin. I am surprised they don't mentio…

I don't understand this. Why would it be sending queries and redoing on a replica and sending the WAL? Just sending the WAL would seem to be sufficient, or alternatively: sending queries would be redundant if you just send the WAL and apply directly at the secondaries.
Post reply on HN