Uber has been in the news for numerous reasons in the past few days. Be it expansion to new countries or selling its China operations to Didi chuxing, Uber is growing exponentially and expanding into newer markets. Recently, Uber also announced a major change – Changing their databases from Postgres to MySQL. While enterprises are constantly checking and trying to find the right fit for their databases, it takes immense research and analysis to decide on THE one.
Each enterprise has their own requirements and it is imperative for the company to decide on the database that suits their needs. This is exactly what Uber did. Uber recently shared a blog detailing various issues they faced using Postgres and what prompted them to make the change to MySQL.
One of the main limitations faced by Uber was its inability to optimize their upgrading process which resulted in downtime. And we all agree to the fact that, downtime is the biggest enemy of a growing enterprise. Some of the key issues faced by Uber include:
All these factors affected Uber in a number of ways, both from the enterprise as well as engineering view-point. Postgres required high bandwidth that resulted in higher incurred cost and time to the company. Data corruption can have a critical impact on the enterprise and one cannot afford such an issue with data. Moreover, upgrading to newer releases meant long downtime and time consumption which affects the timeframe for scaling up for a growing enterprise like Uber.
Postgres worked for Uber during the early days. However, it was not the most appropriate match while scaling up their operations. MySQL, on the other hand, is more sustainable and helps in better management of large databases.
MySQL helps overcome these critical limitations that have triggered Uber’s decision to shift its database.
There are a number of architectural differences but the most important of them all is that Postgres directly maps index records to on-disk locations but InnoDB maintains a secondary structure. InnoDB secondary index records hold a pointer to the primary key value and a secondary index in MySQL associates index keys with primary keys. All in all, this requires less number of updates for indexes. Moreover, the data is normalized which optimizes the key lookup and the row updates only need to update index records that are actually changed by the row update.
The Undo Log was used which helped Uber engineering when old transactions were needed to reference a row for the purposes of MVCC. The architecture helped them make vacuuming and compaction more efficient for their databases.
MySQL supports multiple replication modes:
The biggest advantage it provided was almost zero downtime while updating replicas to newer versions.
Caching is done differently in both the databases. Postgres accesses data via the page cache which is expensive to certain degree as compared to accessing RSS memory. InnoDB storage engine implements it’s own LRU in InnoDB buffer pool, which has massive upsides:
We feel there is always a trade-off between different databases. Primarily, it depends on the company’s specific requirements and the scale at which their business operates. For most cases, we feel that MySQL is the most scalable and secure database.
Over the years, companies have tried their hands on various databases for their business operations. However, many come back to MySQL due to its core advantages as mentioned above. Hence, we do believe that MySQL is here to stay, making it a perfect choice for emerging enterprises.
What do you think? Let us know your thoughts in the comments section below.
MONyog is a leading monitoring tool that helps you secure your servers and scale up. You can download our 14-day free trial here.