Не в курсе цен, но IMHO 10-человеко-лето-зарплат сопоставимы с ценой годовой поддержки их инстанса.

Лучше потратить 10 человеко-лет (10 человек * 1 год - это в масштабах Яндекса примерно 0) на переписывание и полностью контролировать ситуацию, чем внезапно оказаться с окирпичившейся ввиду каких-нибудь очередных "санкций" БД.  Если PG тянет такие объёмы - то почему бы его и не использовать.

Да, не совсем понятно. Сначала:

Но главная причина перехода — это деньги. Oracle стоит дорого.

Что было бы совершенно правильно (если кто-то считал). Т.е. есть выгода по TCO — Oracle (и вообще всё что угодно) стоит выбросить.

Но далее:

В октябре 2012 года, больше 4 лет назад, было принято решение о том, что мы должны избавиться от Oracle. Не звучало слов PostgreSQL, не звучало каких-либо технических подробностей — это было чисто политическое решение: избавиться, срок в 3 года.

Что уже куда менее понятно — как можно сравнивать TCO Oracle с TCO вообще неизвестно чего?!
В общем, причины не раскрыты, IMHO. ;)

Хз... Это считать надо. Там много нюансов. По стоимости оборудования, например. PG стал жрать сильно больше железа. При этом нигде не указано, чтобы они использовали Advanced Compression, например. Скорее всего его и не было. А был бы - оракловая база ещё раза в 3-5 могла меньше быть..
Опять же. Они пишут, что неактивных юзеров можно на медленные диски. С партиционированием это делается легко. Можно на совсем дешманские скинуть.

В общем, я прям не увидел, чтобы они решили какую-то проблему, которой не могли бы решить при желании на Оракле. Пример исключительно политический.

У них странное отношение к Oracle. Они там своё Exadata на коленке строят

Ага... Мне вообще кажется, что у них что-то вроде челленджа внутреннего. Отказаться от Оракла. Ведь они Яндекс, они всё могут. Спецы крутые...
При этом по факту обоз и сейчас там. У меня друг ораклист там работает, никто его не гонит.. Работа есть, и будет.

за Advanced Compression надо отдельно платить

и бизнес код в базе - это плохо. в любой базе. это не маштабируется. это уже проходили.

Это только Ваше мнение. И это тоже уже проходили (holywars по этому поводу происходят систематически, да).

Надо. Но он окупается. БД реально быстрее работает как правило, и занимает меньше. Ты можешь выиграть в ядрах (которые основная цена) и по месту.
По моему опыту большинство баз легко жмутся в 3-5 раз.

Да, норм это тема, если тебе не приходится тонну данных постоянно тащить наружу.. Просто надо без фанатизма. Не надо запихивать целую операционку в БД...

видел лет 7 назад как работает расчет зарплаты, полностью написанный на PL/SQL для обной большой организации (порядка 100 тыс человек). Сервер просто был загружен по 100% и сделать ничего нельзя было.

вот вам и пример бизнес кода в бд.

Вот что реально крутого Яндекс сделал в плане СУБД - это Clickhouse. Под задачи хранения timeseries данных прям топчик. А у них это основной объем всегда был...

да, CH годнота

А, если тот же код был реализован на стороне 10 серверов приложений, и грузил бы их на 50%, это считалось бы нормой?

у яндекса не только КХ. они еще yandex DB создали. просто она скорее закрывая, а КХ откытый, но идеи там еще более современные, чем в КХ

их дешевле маштабировать. в oracle упирались в cpu. сервер oracle так просто не маштабируется.

Кстати:

> PG стал жрать сильно больше железа.

Они хотели этого, вроде. Но "жрать сильно больше железа" с Oracle сильно дороже, насколько я понял.
Вообще, это всегда противная проблема с коммерческими СУБД — вот было бы удобно / полезно развернуть "тестовый" сервер, и вот же "железо" (и обслуживание) стоило бы, к примеру, всего 10000$... но тут понимаешь, что +лицензии СУБД (которые ещё надо аккуратно посчитать, в отличие от) превращают эту сумму, в, к примеру, 100000$... и что-то нового сервера уже совсем не хочется. :(

> С партиционированием это делается легко.

Могли бы и в PostgreSQL это сделать (особенно теперь).

> В общем, я прям не увидел, чтобы они решили какую-то проблему, которой не могли бы решить при желании на Оракле.

<troll>
К примеру, нет проблем (в области применения), которые нельзя решить на COBOL-е. Так давайте останемся на нём навсегда?  Тем не менее, от него все в ужасе бегут... по политическим причинам, наверное.
</troll>

Там же в статье чётным по белому написано, что отказались от Оракла по политическим. Все описанные проблемы решаются в Оракле его средствами. Просто это никто не делал, т.к. надо перейти на PG, и махать флажками, что они молодцы... =)