>> Причины, по которым Uber возвращался с PostgreSQL на MySQL, в основном ещё
>> актуальны.
>Если они изначально делали все под MySQL, то не удивительно. А так по моему опыту использования >Postgres и MySQL с рельсами, Postgres даже на глаз быстрее работает.

Я мог конечно не так понять, но вроде обоснования были такие. Там вроде одна из проблем была - массированные обновления строк. У постгреса с этим не очень хорошо (по крайней мере было, как сейчас - не знаю), тормозил нещадно по сравнению с мускулем. Поясню. У других БД (оракл, мускуль...) строка обновляется на том же месте, где валяется (in-place), т.е. ее физическое положение в блоках не меняется, кроме редких случаев. А постгря вместо редактирования старой строки тупо добавляет измененнную новую. Вроде должно быть даже быстрее, типа некий аналог Copy-on-write. Проблемы возникают, когда на таблицу навешаны индексы. Индекс - упорядоченная последовательность значений, где с каждой строчкой индекса хранится ссылка на исходную строку в таблице, в каких блоках она находится по каким смещениям. В оракле-мускуле, если в строке обновляются поля, не входящие в индекс, индекс не редактируется (адрес строки в таблице не поменялся). А вот в постгре даже при обновлении не-индексных полей надо каждый раз искать в индексе и обновлять на адрес новой, обновленной строки - там уже другой адрес, уже в других блоках ошивается строка, т.е в индексе хранится фигня, надо исправить. Т.е. представь, в таблице у тебя один-два-три индекса, для поисков, а ты 24/7 массированно меняешь поля, не входящие в индекс - и совершается куча лишней (в сравнении с мускулем) работы по обновлению индексов, да еще и куча мусора остается в виде старых исключенных строк, которые какой-нибудь автовакуум подобрать должен, периодически внося свои тормоза и задержки.