Editorials

Which SQL Engine is Right For My System?

I was reading a paper from Uber regarding their switch from Posgres to MySql. I have to admit that there were a lot of deep dives in their reasoning, with a lot of edge case scenarios not unique to Uber. What I found more interesting was the massive number of responses to the publication. As I followed many of the different links with rebuttals and acknowledgements I found a few interesting trends.

  • There were other companies who had used other database engines, and had moved to Posgres, stating similar kinds of problems, and Posgres was going to solve them.
  • There was a lot of insight regarding how the engine was not designed to do what they were attempting.
  • They may have an architecture that doesn’t scale for their needs.

The key to their complaint was locking and blocking. Transactions were not able to complete quickly enough. As they introduced additional complex features of Posgres such as replication, the problem grew. When they added co-location, the issues grew further.

Some additional issues they experienced were that modifications to the schema were a nightmare. Backup or restore processes may not complete, and potentially corrupted the database.

Where did Uber go wrong? I’m pretty sure, and I found a couple hints alluding, that they are not going to have much better experience with MySql than they did with Posgres,

One rebuttal on the entire logic writes that the need to change was more related to their choice to move to an internal design of a schemaless data store, backed by an SQL engine. It also states that they had just done a recent switch from MySql to Posgres back in 2013. We’ll talk a little more about the Uber problem and solution tomorrow (Schemaless).

I won’t diminish the problem Uber has to solve. It’s a lot bigger than most companies have to manage. Still, are there lessons we should learn from this story? Get into the conversation. Share your insights in our comments.

Cheers,

Ben