Uber switched from Postgres to MySql. https://eng.uber.com/mysql-migration/

If I remember right, though, mostly because their use pattern was more like a key value store, and MySQL worked better for that pattern.

Thank you, very interesting read! They do raise a few good points where MySQL outperforms PostgreSQL. I suppose that's one of the trade offs between them, data safety vs. performance.

> very interesting read!

Well, it's also quite a misleading read as the numerous rebuttals will point out:

http://rhaas.blogspot.co.uk/2016/08/ubers-move-away-from-pos...

https://blog.2ndquadrant.com/thoughts-on-ubers-list-of-postg...

http://use-the-index-luke.com/blog/2016-07-29/on-ubers-choic...

> Uber switched from Postgres to MySql.

really uber should not taken as an example, especially since they failed so hard with their databases in the past.

(I'm a Postgres fan, yes, but I think that there a valid reasons to migrate to MySQL (there are several other companies who use mysql, etc but Uber's stuff is just plain FUD))

Are you sure mysql doesn't enforce foreign key constraints? I recently did a project with mysql backend and it did threw constraint errors on invalid inputs that didn't match a parent key record.

You're partially correct. It does when inserting or updating, but if you do an alter ignore table you can create foreign key constraints that are actually invalid.

So... not in all cases

Doesn’t innodb atleast enforce those constraints?

During most normal operations such as updates, inserts and deletes it will enforce them. But, opposed to other databases, you are allowed to completely ignore your foreign key constraints leaving you with a (in my opinion) possibly corrupt database.

  SET FOREIGN_KEY_CHECKS = 0;
  INSERT INTO ...
  SET FOREIGN_KEY_CHECKS = 1;

Now you might have data in your database that's actually incorrect.

You can do this in postgres as well, with something like:

    begin; alter table t2 disable trigger all;
    insert into t2 (t1_id) values (20);
    alter table t2 enable trigger all;
    commit;

Setting constraints to deferrable/initially deferred[1] is probably a nicer way for any non-insane thing you're trying to achieve with such, though :)

[1] https://www.postgresql.org/docs/9.6/static/sql-set-constrain...

PostgreSQL has the same feature actually, which I learned as part of a MySQL -> PostgreSQL migration that's underway.

    SET session_replication_role TO 'replica';

We need this to load the data in without worrying about table order, or even individual row order for foreign keys that reference their own table.

And we'll all try and forget this feature exists when we're done!