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

111–120 of 133 posts

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

#111

Post by rleigh »

mgkimsal wrote: post #64
looperhacks wrote: post #18

Earlier quoted context omitted.

How is creating a new user complicated? The normal CREATE USER is all I've ever needed to create a new user in postgres (assuming I don't have set up the pg_hba so that I need to allow every user separately)

Most tutorials/instructions I read have you use "createuser" command from the system shell. But... you have to be able to switch to a system 'postgres' user first , which ... perhaps you don't have privileges to do, or need sudo access or whatnot. If you can install postgres, connect to it directly with some sort of root identity , then immediately create users and databases (as is the case with pretty much every mys…

This depends entirely on how you want to set up and run the system. For packaged versions running as a system service with a dedicated service user, this is absolutely correct. And I would argue, it's a pretty sensible default arrangement.

But... there's absolutely nothing prohibiting you from running initdb as a regular user and then running the main daemon with your credentials. You are then the database owner and superuser. This type of thing is really useful for integration testing. But it's potentially useful when you don't care about the multiuser aspect and just want to have it run.

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

#112

Post by rleigh »

mvanbaak wrote: post #42
tinus_hn wrote: post #22

Earlier quoted context omitted.

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.

pgadmin ;-P

Or DataGrip if you already have a JetBrains licence.

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

#113

Post by dang »

ignoramous wrote: post #5

Previous discussions: 2016: https://news.ycombinator.com/item?id=12166585 2018: https://news.ycombinator.com/item?id=17280239 Community responses: - https://news.ycombinator.com/item?id=12216680 - https://news.ycombinator.com/item?id=12179222

Thanks! Here's an annotated list of all those (plus chris_wot's and a couple others):

Why Uber Engineering Switched from Postgres to MySQL (2016) - https://news.ycombinator.com/item?id=17280239 - June 2018 (47 comments)

Re: Why Uber Engineering Switched from Postgres to MySQL - https://news.ycombinator.com/item?id=12179222 - July 2016 (67 comments)

Why Uber Engineering Switched from Postgres to MySQL - https://news.ycombinator.com/item?id=12166585 - July 2016 (294 comments)

Thoughts on Uber’s List of Postgres Limitations - https://news.ycombinator.com/item?id=12216680 - Aug 2016 (103 comments)

A PostgreSQL response to Uber [pdf] - https://news.ycombinator.com/item?id=14222721 - April 2017 (82 comments)

Why we lost Uber as a user - https://news.ycombinator.com/item?id=12201353 - Aug 2016 (285 comments)

Uber's Move Away from PostgreSQL - https://news.ycombinator.com/item?id=12223216 - Aug 2016 (15 comments)

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

#114

Post by tinus_hn »

jhauris wrote: post #66
tinus_hn wrote: post #55

Earlier quoted context omitted.

This actually looks pretty reasonable, I am going to look into it. First I need to figure out how to open up the server for connections but still limit it, though.

Look at the pg_hba.conf file (probably something like /etc/postgresql/ /main/pg_hba.conf). https://www.postgresql.org/docs/current/auth-pg-hba-conf.htm...

Perhaps it’s better to only listen to localhost and connect through a SSH proxy connection

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

#117

Post by throwdbaaway »

evanelias wrote: post #81
throwdbaaway wrote: post #21

Earlier quoted context omitted.

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

To echo and add to rwultsch's sibling comment: * Facebook had extremely frequent schema changes, and powerful declarative schema management automation to support this * The TAO (or more correctly "UDB") use-case supported using many separate tables, not one giant generic key/value table as people seem to assume * The non-UDB MySQL use-cases at Facebook, in combination, are still larger than the vast, vast majority of…

Thanks for the insight! So how frequent does schema change happen to UDB?

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

#118

Post by evanelias »

throwdbaaway wrote: post #117
evanelias wrote: post #81

Earlier quoted context omitted.

To echo and add to rwultsch's sibling comment: * Facebook had extremely frequent schema changes, and powerful declarative schema management automation to support this * The TAO (or more correctly "UDB") use-case supported using many separate tables, not one giant generic key/value table as people seem to assume * The non-UDB MySQL use-cases at Facebook, in combination, are still larger than the vast, vast majority of…

Thanks for the insight! So how frequent does schema change happen to UDB?

Sorry, I don't recall the exact frequency, I left FB in 2015.

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

#119

Post by evanelias »

Tostino wrote: post #110
evanelias wrote: post #84

Earlier quoted context omitted.

On the one hand, MySQL has offered this for two decades, by virtue of pluggable storage engines being core to its design. Some storage engines use clustered indexes and some do not. The user can decide which one matches their use-case; very large companies can design their own custom special-purpose storage engines; etc. On the other hand, mixing storage engines in a single db instance has operational downsides (espe…

It'll be interesting to see how things shake out when some of the other implementations using postgres's pluggable storage API start maturing. I wonder if it'll have some of the same operational downsides that mixing storage in MySQL has.

Good question. I assume it depends on how Postgres handles multi-engine transactions, and how it stores replication state metadata. A good discussion of the issue in MySQL/MariaDB is here: https://kristiannielsen.livejournal.com/19223.html

Apparently MariaDB 10.3+ has this solution implemented, which is cool, never knew that before. I don't think there's anything equivalent in MySQL.

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

#120

Post by EdwardDiego »

mmcgaha wrote: post #48
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.

Arrays in Postgres are my guilty pleasure. I know I shouldn’t use them but I just cannot help myself.

I've recently used them to replace a many to many relation from table A to table B where the primary query was "give me all As associated with B", so the new table had a schema of unique B, Array, so what was a 20ish second query over several hundred million rows became a 0.3 second query over 600K rows.

We did have a use case that wanted to find Bs for a given A, and using a GIN index on the array column along with the PG array contains operator served that up remarkably fast also.

Post reply on HN