Live data from Hacker News

Why Uber Engineering Switched from Postgres to MySQL (2016)

eng.uber.com

101–110 of 133 posts

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

#101
post #54
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.

That was added a couple years ago in MySQL 8, as were window functions and arbitrary checks. The two databases continue to fill in the gaps that were historically reasons to choose one over the other.

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

#102

Earlier quoted context omitted.

With MySQL, you'll still have to switch to root to connect by default? I honestly don't remember, since it's been ages since I set up MySQL manually. If MySQL actually allows administrative access out-of-the-box without any kind of special authorization, then that's a terribly insecure default. With PostgreSQL, you have to switch to the superuser to configure things further because that's the only sane default you ca…

"With MySQL, you'll still have to switch to root to connect by default? " You connect with a root account from any account, and when installed, the root account password is part of the setup process. "and the same user at different addresses or auth methods can have different permissions".... It joe@localhost and joe@remotehost don't have to be 'the same user' in that they're not tied to a system account in any way.…

I'm just not sure how it's confusing? PostgreSQL users aren't "tied" to system accounts either. You can have any number of PostgreSQL users that have no system equivalent.

In fact, the process seems to be exactly the same as with MySQL: I just tried installing the MariaDB server (dnf install mariadb-server), and it didn't prompt me for an admin user; instead, I can directly connect to the database as root using sudo, so in this case it appears to be doing the exact same thing that PostgreSQL does.

It just happens to be that by default the "postgres" superuser has a corresponding "postgres" system user that can log in via OS authentication, so you need to switch to the postgres user instead of root.

EDIT: Maybe some of the confusion stems from the fact that the documentation you linked seems to assume that the database is created according to convention to run as the "postgres" user (as it usually is). If your user didn't have the required permission to switch to the postgres user, they wouldn't be able to install the database as said user in the first place.

If you install PostgreSQL as your own user (which is not a good idea if you have any other option), you will not need to switch users as you will obviously have access to the database files and can do whatever you want, anyway.

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

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

That was added a couple years ago in MySQL 8, as were window functions and arbitrary checks. The two databases continue to fill in the gaps that were historically reasons to choose one over the other.

Are Mysql 8 DDL changes transactional across tables? If not then in what sense are they transactional?

Because to this day I still have to deal with locking problems unless my changes are within a narrow window: last column, no on-update or on-delete, not changing type, etc.

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

#104
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?

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.

both kubernetes operators have some ok user management built in

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

#105
post #7

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?

"What the hell is scoping? Why not put every variable in global scope? Much less complex"

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

#106
post #92
post #87

Earlier quoted context omitted.

I think this applies to most companies. What they write in their blogs is a shiny, optimistic, limited view of the best part of their best system or similar. Once inside, things are never that great. I myself was very ashamed of a company I worked for (also SF based) blog post... even the author of the post was a very well known open source maintainer of many libraries of a very popular programming language. Reading…

Can we maybe get a list of company blogs that are legit? As in they practice what they preach? Facebook, Amazon, Netflix Google, Microsoft comes to the top of my head but someone is free to burst my bubble.

Figma and Instagram have had good articles on their blogs, although I'm not a regular follower of either.

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

#107
post #92

Earlier quoted context omitted.

Can we maybe get a list of company blogs that are legit? As in they practice what they preach? Facebook, Amazon, Netflix Google, Microsoft comes to the top of my head but someone is free to burst my bubble.

Cloudflare's blogs seem far less markety and far more about sharing interesting technical wins.

I've dealt with cloudflare people semi-regulary recently and they seem to know their shit, they also (from an outside perspective) seem to have a really good culture.

Questions get answered quickly and with a level of detail appropriate to the person asking.

Really impressive given the usual "Enterprise(TM)" level of support from most service suppliers.

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

#108
post #83

There's some historical context for this article. 2016 was a year of RAPID growth for Uber. There was a running statistic internally that your employee ID would be at the median point just 6 months after being hired. They were trying to hire (and poach) just about anyone they could around this time. Therefore, these articles are... very shiny, compared to the actual tech applied internally (note that even though Uber…

is schemaless still the db now?

No idea, but I would wager so. The scale it was being used at would be hard to replace, and they'd have little reason to do so.

EDIT: To be clear, there is no "the DB" at Uber. It was the main database flavor that the larger teams used, but they used everything at Uber, from MySQL to postgres, to mongo, etc. Sometimes with things on top, sometimes directly. For more analytical/financial things, they used HBase/Hadoop/Cassandra, or even older things like old IBM database tech from the 80's. Really weird mix of stuff, and it really depended on which high-profile engineers they hired in which part of the company.

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

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

I remember reading the MySQL developers justifications for why transactions weren't important along with articles such as these back in the 00s

https://sql-info.de/mysql/gotchas.html

https://fromdual.com/mysql-limitations

and deciding a database that treats 1/0 as NULL and allows inserting February 31st as a valid date wasn't worth bothering with.

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

#110

Earlier quoted context omitted.

The main point, clustered vs. nonclustered indexing, is architectural, and not inherently inefficient; it depends on the use case. "Highly advanced" databases give both options, but AFAIK, MySQL/PGSQL will likely not offer this, at least for a very long time, since it requires radical changes.

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.
Post reply on HN