I think this slideshow is doing the project a disservice. Mysql is definitely a "lesser" database, that seems to be widely known and accepted. It seems to be al

I think this slideshow is doing the project a disservice. Mysql is definitely a "lesser" database, that seems to be widely known and accepted. It seems to be also very frustrating for the PostGres team that that is not the sole factor, but it isn't. For a shared database it's not even that high up there. This slideshow is bemoaning that Uber seems to find the design decisions of PostGres a problem. Really, they're fine decisions "just get a department to deal with them", is the message. And yes, that is very much the PostGres attitude. The great thing about MySQL is that it generally just keeps working with incredibly small amounts of maintenance whereas PostGRESQL just constantly needs attention. This has always been my personal complaint. From vacuuming (yes I used PostGRESQL before autovacuum, and you can still fuck up autovacuum) to upgrades, everything is just fiddly fiddly fiddly. The end result is that mysql, you start it, you run it, you do your normal OS upgrades and everything just kinda hums along. For years and years. PostGRESQL is like all enterprise solutions : you start it and run it and a month or so and it suddenly refuses to accept connections, or suddenly it starts using too much disk (e.g. misconfiguring autovacuum), or ... It has a bazillion things you need to configure and make cooperate and there's large procedures for everything you need do to. Every week some warning light goes all flashy and won't stop flashing until it made you press a few buttons where it was perfectly predictable which buttons needed to be pressed. It forces you to consider 2000 configuration options, rather than picking sensible defaults, instead asking. But yes, you get something back for that. A bigger, better, more correct and far more featureful database. In many ways it starts having the issues of other large databases (e.g. the 3-page-and-totally-inscrutable SQL stored procedure functions). This is very much a case of "pick your poison". But frankly, if you want your app to just run, like we all do, MySQL will serve you better. If your OCD can't deal with small imperfections, datatypes that fit only 99%, having values that your text mode SELECT in the database can't print ... if those bother you, stay away from MySQL. And of course the classic, if you have a "real database workload" (very heavy load with constant reads AND constant writes), yes you probably need PostGRESQL. You could say Mysql is halfway between LevelDB and PostGres. By the way, if you need a mobile database with zero maintenance, SQLite will serve you even better. It can't be shared with other applications and is not meant for database-behind-network approaches, but you'd be surprised how well it can work.