Uber Engineering explains the technical reasoning behind its switch in database technologies, from Postgres to MySQL: https://eng.uber.com/mysql-migration/
These things are always an interesting read, because it looks at one company’s decision making process and operational steps.
At Open Query we’re not a fan of migrations – it doesn’t matter from what brand to what brand, migrations tend to be expensive and painful. Any application tends to be more suited to a particular brand – because of design and implementation choices. This is neither good nor bad, it’s just a fact that has to be acknowledged when considering these things.
Similarly, infrastructure (what hardware there is and how it’s set up and connected) tends to be dependent on the brand choice, as different databases have different needs in that space, particularly when looking at replication and clustering as well as with larger data stores.
Consequently, moving to another brand is (most likely) going to be less optimal – unless the original was really not optimal (for the original brand it ran on). Commonly happens when either an attempt was made to keep the application brand agnostic (this tends to work out very badly for performance and scalability), or if the schema design, infrastructure or application was developed by people with experience in a different brand – then some of their design decisions might have been suited for that brand they’re familiar with, but not the brand they were actually deploying on in this particular instance.
So in our opinion, there’s no such thing as a “better database”. What works best in a particular case depends on many things, including the practical needs, but also any pre-existing hardware and codebase as well as experience/expertise of developers and other people. For instance, if a desired brand cannot be efficiently deployed on the existing hardware but there is no budget to replace that infrastructure, it would be folly to move to that brand as it just wouldn’t perform effectively – and quite likely cause significant troubles (beyond the migration process itself).
The fact that Uber moved from one brand to another doesn’t mean that that’s the best choice for anybody else. Every situation is different. There are valid reasons for choosing to go the difficult path of database migration, but it needs to be very carefully considered. In the case of Uber, they choose to use a special “schemaless” layer on top of MySQL, which would completely change the way things work. Certain schemas and query constructs are more optimal in one brand than another, but when you add such extensive abstraction layers on top, it gets even more complex.