Stories
Slash Boxes
Comments

SoylentNews is people

SoylentNews is powered by your submissions, so send in your scoop. Only 17 submissions in the queue.

Why Uber switched from Postgres to MySQL

posted by n1 on Thursday July 28 2016, @06:30AM   Printer-friendly
from the they-forgot-about-mssql dept.

[redacted] Coward writes:

https://eng.uber.com/mysql-migration/

The early architecture of Uber consisted of a monolithic backend application written in Python that used Postgres for data persistence. Since that time, the architecture of Uber has changed significantly, to a model of microservices and new data platforms. Specifically, in many of the cases where we previously used Postgres, we now use Schemaless, a novel database sharding layer built on top of MySQL. In this article, we’ll explore some of the drawbacks we found with Postgres and explain the decision to build Schemaless and other backend services on top of MySQL.

[...] We encountered many Postgres limitations:

Inefficient architecture for writes
Inefficient data replication
Issues with table corruption
Poor replica MVCC support
Difficulty upgrading to newer releases

Original Submission

 
This discussion has been archived. No new comments can be posted.
Why Uber switched from Postgres to MySQL | Log In/Create an Account | Top | 34 comments | Search Discussion
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

  • (Score: 1) by Bronster on Friday July 29 2016, @02:56AM

    by Bronster (356) on Friday July 29 2016, @02:56AM (#381408) Homepage

    Wow. I didn't read that at all.

    I run Cyrus IMAP with its application level replication protocol rather than DRBD under the hood because I know that I can screw up and break the internals in various ways - and I'd rather be shipping descriptive changes with protocol level invariant checking rather than shipping raw disk blocks and replicating any corruption without being able to apply additional sanity checks at the replication layer.

    (I've also run MySQL in production, purely InnoDB, for over 10 years without data being destroyed, so I'm amused at your FUD about how it will corrupt your database)

  • (Score: 2) by stormreaver on Friday July 29 2016, @01:05PM

    by stormreaver (5101) on Friday July 29 2016, @01:05PM (#381510)

    I've also run MySQL in production, purely InnoDB, for over 10 years without data being destroyed, so I'm amused at your FUD about how it will corrupt your database

    I was being a bit hyperbolic about MySQL's data corruption, but the basic idea is true. MySQL changes your data to fit its constraints, rather than telling you that you passed bad data (which is once of its frequent data corrupting mis-features). And MySQL has a long and steady history of spontaneous database corruption after the fact, for no apparent reason other than bad internals.

    I've watched MySQL self-destruct enough times to no longer even consider it an option for anything even remotely important.