Re: Uber migrated from Postgres to MySQL

From: Geoff Winkless <pgsqladmin(at)geoff(dot)dj>
To: Scott Mead <scottm(at)openscg(dot)com>
Cc: PostgreSQL General <pgsql-general(at)postgresql(dot)org>
Subject: Re: Uber migrated from Postgres to MySQL
Date: 2016-07-27 15:51:42
Message-ID: CAEzk6fdbB-VBpy8=EV-9g2odOrDrUUgM3AiEkwz7meNgnX_BHg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 27 July 2016 at 15:22, Scott Mead <scottm(at)openscg(dot)com> wrote:

> "The bug we ran into only affected certain releases of Postgres 9.2 and
> has been fixed for a long time now. However, we still find it worrisome
> that this class of bug can happen at all. A new version of Postgres could
> be released at any time that has a bug of this nature, and because of the
> way replication works, this issue has the potential to spread into all of
> the databases in a replication hierarchy."
>
>
> ISTM that they needed a tire swing
> <http://i0.wp.com/blogs.perficient.com/perficientdigital/files/2011/07/treecomicbig.jpg>
> and were using a dump truck. Hopefully they vectored somewhere in the
> middle and got themselves a nice sandbox.
>


At least his bug got fixed. The last 2 bugs I reported to MySQL resulted in
an initial refusal to accept any problem existed, followed by (once that
particular strategy had run out of steam) the developer simply ignoring the
bug until it was closed automatically by their bug system. As far as I'm
aware those bugs still exist in the most recent version.

Admittedly they weren't data-corruption bugs but they were of the "this
will cause your application to unnecessarily come to a complete halt for a
couple of hours once your dataset grows beyond a certain point" variety.

As others have pointed out, db changes very rarely happen because of
technical reasons. Most developers will harp on at their boss about how
terrible their current database is and how <preferred database> performs
much better. Eventually one of two things happens: either a) those
developers end up in a position where their direct boss is in a position to
make the change and he or she doesn't understand how much time and money it
will actually take to change; or b) commercial considerations dictate the
change.

The amount of money and time they've wasted making this change (and
whatever anyone tells you these things never come for free) would have been
better invested in employing one of the commercial PG companies to improve
the specific postgres problems they found. The fact that they decided to go
the MySQL route suggests to me that this was a political, not technical,
change, and they're now reverse-justifying.

For what it's worth, from what I've read uber are a company whose very
business plan relies on them taking things that they don't deserve while
they treat customers and employees with similar levels of arrogance.
Frankly I'd rather there were as many levels of separation as possible
between me and them: they and Oracle are welcome to each other, it seems
like a marriage made in heaven.

Geoff​

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Andrew Sullivan 2016-07-27 16:11:44 Re: Uber migrated from Postgres to MySQL
Previous Message Bruce Momjian 2016-07-27 15:45:01 Re: Uber migrated from Postgres to MySQL