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

61–70 of 133 posts

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

#61

Post by colanderman »

lucian1900 wrote: post #52
mmcgaha wrote: post #48

Earlier quoted context omitted.

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

They’re great for denormalisation, which is often an appropriate trade off.

Yes! Have one-to-many data that you know you will usually always grab all in one go, and won't ever participate in a relation? Arrays are the way to go. JSONB can be similarly highly appropriate. They can greatly reduce the number of disk reads needed for certain workloads.

Don't forget that both can be indexed in Postgres! And the indexes are more powerful than what you can do with the equivalent relational layout, as they support efficient subset queries.

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

#63

Post by rrauenza »

noir_lord wrote: post #31
bombcar wrote: post #29

Earlier quoted context omitted.

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.

You should definitely have a gander.

Especially at the possibilities of a lack of down time.

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

#64

Post by mgkimsal »

looperhacks wrote: post #18
eznzt wrote: post #7

Earlier quoted context omitted.

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

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 mysql walk-through I've ever seen), it's not a default.

https://wiki.postgresql.org/wiki/First_steps

"The default authentication mode is set to 'ident' which means a given Linux user xxx can only connect as the postgres user xxx."

This alone is a complicated/confusing thing, because it's mixing system accounts with the db server accounts/access - and none of that is obvious, and doesn't quite map to how other databases handle things. I've never had to have matching system account names for user access in MSSQL, for example.

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

#65

Post by chousuke »

tpetry wrote: post #54
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.

The best part is transactional ddl statements. You can do your database migration in a transaction, if something fails the transaction is rolled back compared to an invalid state with mysql.

Being used to PostgreSQL, this one actually bit me once during a production upgrade. A database migration failed due to a Galera transaction size limit that I unfortunately hadn't caught testing the migrations on a single database, and I had to restore from the pre-upgrade backup before resolving the issue and continuing. It wasn't a major issue (the upgrade finished well within the acceptable downtime window), but until then I had assumed that the migrations would be transactional because of course they should be, it's a database!

Now I know better than to assume everything you do in a database is transactional. :P

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

#66

Post by jhauris »

tinus_hn wrote: post #55
mvanbaak wrote: post #42

Earlier quoted context omitted.

pgadmin ;-P

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...

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

#68

Post by axegon_ »

darksaints wrote: post #51
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.

Postgres was my first, and the Postgres docs were foundational for someone like me. Tried MySQL a couple years later, and every day I used it I found a new reason to never use it again.

If you liked the docs, you should definitely check out the source code. It's not just poetry by C standards, it's poetry by Shakespearean standards. Hands down the best code I've ever seen. What makes it more astonishing is that it's a product of relatively small community scattered around the globe.

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

#69

Post by spuz »

chousuke wrote: post #65
tpetry wrote: post #54

Earlier quoted context omitted.

The best part is transactional ddl statements. You can do your database migration in a transaction, if something fails the transaction is rolled back compared to an invalid state with mysql.

Being used to PostgreSQL, this one actually bit me once during a production upgrade. A database migration failed due to a Galera transaction size limit that I unfortunately hadn't caught testing the migrations on a single database, and I had to restore from the pre-upgrade backup before resolving the issue and continuing. It wasn't a major issue (the upgrade finished well within the acceptable downtime window), but u…

Which database are you talking about? Postgres or Mysql?

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

#70

Post by petergeoghegan »

I committed a patch that added a mechanism I called "bottom-up index deletion" recently:

https://www.postgresql.org/docs/devel/btree-implementation.h...

https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit...

Bottom-up deletion is specifically designed to ameliorate what the blog post refers to as "write amplification". Testing has shown that it's very effective with many workloads.

Post reply on HN