5 ms·

Uber switched from mysql to postgres in 2013: https://www.yumpu.com/en/document/view/53683323/migrating-uber-from-mysql-to-postgresql https://www.yumpu.com/en/

by rawnlq 10y ago

Uber switched from mysql to postgres in 2013: https://www.yumpu.com/en/document/view/53683323/migrating-uber-from-mysql-to-postgresql https://www.yumpu.com/en/document/view/53683323/migrating-ub... but switched back to mysql in 2016 which generated a lot of discussion: https://news.ycombinator.com/item?id=12166585 https://news.ycombinator.com/item?id=12166585 There were a lot of followup posts afterwards arguing both sides if you search for them: https://news.ycombinator.com/item?id=12216680 https://news.ycombinator.com/item?id=12216680

no1youknowz 10y ago
I thought the reason for migrating over was for MemSQL? Here is a video "Real Time Analytics at UBER Scale": https://www.youtube.com/watch?v=XSXvPNEykb4 https://www.youtube.com/watch?v=XSXvPNEykb4
RedCrowbar 10y ago
There's an excellent analysis of the Uber's post here: http://use-the-index-luke.com/blog/2016-07-29/on-ubers-choice-of-databases http://use-the-index-luke.com/blog/2016-07-29/on-ubers-choic...
heimatau 10y ago
It's strange to me everyone touts Postgres but when you finally scale to a medium to large architecture HN has a handful of articles on great start-ups (now full fledge companies) switching FROM Postgres to MySQL. It's more efficient, atm, especially when accounting for labor. I wish the HN community would see that.
- falcolas 10y ago
  There are more MySQL experts out there than there are PostgreSQL experts (though the number is still probably under 10,000 worldwide). MySQL replication and scaling is a well understood solution, and thoroughly battle tested. There are dozens of good solutions out there for handling near-instantaneous failovers, using little more than the tools provided by MySQL. It has a lot of problems, but when you need to scale, you can do so much more affordably with MySQL.
snuxoll 10y ago
In Uber's case they wanted a dumb K/V store, not a full RDBMS. MySQL is a better choice here, InnoDB is a great K/V store, but PostgreSQL is a better relational database assuming you're using the features it provides.
- evanelias 10y ago
  Regarding InnoDB being a great K/V store, you made a similar claim yesterday, but you haven't really explained your rationale in either thread. Care to do so? EDIT: I'm referring to https://news.ycombinator.com/item?id=14067406 https://news.ycombinator.com/item?id=14067406 ; my reply to that comment included more specific questions. Unsure of why receiving downvotes here; being somewhat of an InnoDB expert myself, I am legitimately curious why the parent keeps making assertions about InnoDB being a K/V store.
  - snuxoll 10y ago
    That's because InnoDB IS a key-value store, the physical on disk structure is such that rows are stored on disk by their primary key, and that's how MySQL is designed. Postresql's heap files are organized much differently, as such it performs worse in some cases like Uber's.
    - evanelias 10y ago
      That's a clustered index, but it does not inherently make it a key/value store. It is common practice in SQL Server to use a clustered index for tables; would you also think of that as a key/value store? Most database people don't describe clustered indexes in this way. Also, you're describing how InnoDB is designed, not how MySQL is designed. Furthermore, you can effectively get a heap in InnoDB if a table has no PK and no unique indexes. InnoDB will internally use a hidden auto-incremental value in this case for the primary lookup, which more or less effectively acts as a row pointer.

by rawnlq 10y ago

no1youknowz 10y ago

I thought the reason for migrating over was for MemSQL? Here is a video "Real Time Analytics at UBER Scale": https://www.youtube.com/watch?v=XSXvPNEykb4 https://www.youtube.com/watch?v=XSXvPNEykb4

RedCrowbar 10y ago

There's an excellent analysis of the Uber's post here: http://use-the-index-luke.com/blog/2016-07-29/on-ubers-choice-of-databases http://use-the-index-luke.com/blog/2016-07-29/on-ubers-choic...

heimatau 10y ago

It's strange to me everyone touts Postgres but when you finally scale to a medium to large architecture HN has a handful of articles on great start-ups (now full fledge companies) switching FROM Postgres to MySQL. It's more efficient, atm, especially when accounting for labor. I wish the HN community would see that.

falcolas 10y ago
There are more MySQL experts out there than there are PostgreSQL experts (though the number is still probably under 10,000 worldwide). MySQL replication and scaling is a well understood solution, and thoroughly battle tested. There are dozens of good solutions out there for handling near-instantaneous failovers, using little more than the tools provided by MySQL. It has a lot of problems, but when you need to scale, you can do so much more affordably with MySQL.

snuxoll 10y ago

In Uber's case they wanted a dumb K/V store, not a full RDBMS. MySQL is a better choice here, InnoDB is a great K/V store, but PostgreSQL is a better relational database assuming you're using the features it provides.

evanelias 10y ago
Regarding InnoDB being a great K/V store, you made a similar claim yesterday, but you haven't really explained your rationale in either thread. Care to do so? EDIT: I'm referring to https://news.ycombinator.com/item?id=14067406 https://news.ycombinator.com/item?id=14067406 ; my reply to that comment included more specific questions. Unsure of why receiving downvotes here; being somewhat of an InnoDB expert myself, I am legitimately curious why the parent keeps making assertions about InnoDB being a K/V store.
- snuxoll 10y ago
  That's because InnoDB IS a key-value store, the physical on disk structure is such that rows are stored on disk by their primary key, and that's how MySQL is designed. Postresql's heap files are organized much differently, as such it performs worse in some cases like Uber's.
  - evanelias 10y ago
    That's a clustered index, but it does not inherently make it a key/value store. It is common practice in SQL Server to use a clustered index for tables; would you also think of that as a key/value store? Most database people don't describe clustered indexes in this way. Also, you're describing how InnoDB is designed, not how MySQL is designed. Furthermore, you can effectively get a heap in InnoDB if a table has no PK and no unique indexes. InnoDB will internally use a hidden auto-incremental value in this case for the primary lookup, which more or less effectively acts as a row pointer.