Not in 2015/2016 when so many choices were already available, and certainly not in an org where MySQL would just be more than enough to meet Uber's need. Beside

Not in 2015/2016 when so many choices were already available, and certainly not in an org where MySQL would just be more than enough to meet Uber's need. Besides, Uber built their version on top of MySQL following pretty much FriendFeed's design: https://backchannel.org/blog/friendfeed-schemaless-mysql https://backchannel.org/blog/friendfeed-schemaless-mysql. A strange choice by itself given that better solutions had popped up left and right during the 6 years since the blog was published. Uber switch to Schemaless from a Postgres cluster, claiming that Postgres "does not scale for Uber". I see irony in that piece of Uber history. Particularly, Uber always claimed that some OS solution "had serious reliability issues". Cassandra in 2014 worked for companies that had orders of magnitude of traffic, yet Uber found it unusable. Similarly, Uber switched from MySQL to Postgres and then from Postgres to MySQL. Each time Uber published an article to claim engineering victory. The truth is that any of the three systems would be perfectly fine for Uber. Oh, didn't someone also claim that Elaticsearch crashed under Uber's load" and JVM-based systems were not usable for Uber's scale? " before Uber ended up adopting Elasticsearch? What really happened was that some teams in Uber simply didn't want to dive deep and produce objective tech assessment.