Uber switched from MySQL used as relational database, to Postgres used as relational database, to MySQL used as key-value store.

Nobody is saying MySQL is a bad key-value store!

Is key-value store the most stable scalable architecture? Reddit, I believe, uses the same idea

To restate your other reply, key-value allows you to sweep consistency problems under the rug. What happens if two transactions try to update the same row? One of the transactions fails. What happens if two clients write different values to the same key in a multi-master key-value store? The last one in wins and the first write is just lost.

Many of the NoSQL databases have provisions for these situations so they can handle both writes but bubble the decision up to the application layer. CouchDB, for instance, will tell you you've got multiple versions and has a way for you to tell it how to resolve the conflict. CRDTs let you bake the logic in for handling a conflict. MySQL does not do any of that. If your database consists of "likes" and other low-value data like that, you may not care if you're losing data at some low rate. Reddit is in that situation, and the decision seems to work for them. But I don't think it generalizes to all situations.

If you give up ACID (the C) you can scale more (the P), sure.

https://en.wikipedia.org/wiki/CAP_theorem

I read their article, and a dozen of the rebuttals. If you want to use MySQL badly enough, you can.

> There are many people who would disagree with that. Talking to Uber engineers would probably be a good idea to dispel that myth.

not a good idea, somebody who let their database master run out of storage space is probably not a good source.

Uber is a bad reference for good practices.

The Uber blog post got a lot of things wrong and if that is representative of their knowledge of PostgreSQL I would not suggest using them as an authority on PostgreSQL or databases in general.