Зато дёшево. А каналы туда какие прекрасные (и это актуально в разных странах до сих пор, между прочим).

да, в этом чате точно есть DBA. достаточно крутые. но я имел в виду в реальной жизни не встречал DBA по Postgres. где их искать...)

их растить надо, как и любых других специалистов…

а зачем их растить, если dba, получается, не нужны?

я не согласен с этим утверждением, прям совсем. даже для Oracle.

Есть ещë sql-программисты, они же бд разработчики, они же <вставьте что там у вас на hh написано>
Они тоже как девопсы могут всякое настраивать.

DevOps же вообще не об этом

Да, методология а не роль, и вот это все правильное, но мы уж упрощаем

мне оно тоже сильно не нравится, но показатель востребованности это вакансии, а их очень мало.

+
все зависит от проекта и нагрузки. кол-во пользователей. IOPS. и собсно сам бизнес и требования. для Oracle можно найти сертифицированных и даже не сертифицированных специалистов, которые смогут чтото на 10-20К пользователей поднять. а вот Postgres чтото страдает. в этом и трабла...

Я dba oracle, но умею и SQL Server и Postgres. Обновил резюме на hh, 90 процентов предложений по Postgres dba, остальное sql server и oracle. Не сказал бы что не востребованно.

вот это интересно, спасибо. Значит PostgreSQL у нас всё-таки больше востребован из реляционных баз, для dba

мне кажется, что это не так: (1) они закрываются через поиск кандидатов внутренними способами, не выходя на площадки и (2) они закрываются очень быстро

по п.1 вполне возможно, а вот что закрываются очень быстро - это не совсем так. Я на hh.ru ставлю звёздочки на вакансии для отслеживания, и закрываются они в среднем за пару месяцев, некоторые висят гораздо дольше

> а вот Postgres чтото страдает.

Что там страдает-то?

> в этом и трабла...

"Трабла", IMHO, в том, что PostgreSQL нередко пытаются "поднять" на "железе", которое и на помойку-то выбросить стыдно.
А вот когда кто-то купил лицензии Oracle (почём они там сейчас за ядро? 17000$ или больше?), то полный идиотизм покупки под это железа за 400$ вполне очевиден, и покупают адекватное.
Отсюда и разница в репутации, мне кажется.

справедливости ради, и на Оракл пытаются экономить (ещё как). там надо очень внимательно читать условия.
скажем, не любая система виртуализации позволяет снизить кол-во ядер для лицензирования: вас заставят заплатить по кол-ву ядер на хосте, а не в гостевой ОСи.

"Вас заставят" же только увеличивает стоимость?
Я это к тому, что если бы в подобных случаях можно было бы поменять "железо" местами, Oracle бы ничего не "потянул" (fairy dust в нём нет), а вот PostgreSQL — наоборот. ;)

да, увеличивает.
“прелесть” Оракл в том, что можно всё. только потом заплатить надо будет. и очень много, т.к. некоторые опции очень неожиданны

ну я вероятно о том же. нет у нас DBA, который все может, или почти все.... и там кстате не только в ресурсах же проблема. попросить заоблачные мощности на сервер СУБД - любой может, много ума не нужно. пару дней с заказчиком поругаться и обосновать почему надо больше. а почему СУБД вдруг начинает "чудить" не с того ни с сего - 2 месяца было норм, а седня вдруг процы под 100%. я бы не преуменьшал роль DBA на проектах

тут надо ещё смотреть на то, что Oracle зачастую идёт как требование вендора к покупаемому продукту, и лицензии сразу закладываются в проект и сравниваются при поиске альтернатив.
с Postrges-ом же часто нанимают ребят на разработку софта (и тут даже Postgres возникает, зачастую, случайно), они что-то делают и проект выходит в свет. на этом этапе DBA не рассматривается, ибо дорого и зачем?
а через какое-то время начинаются описанные вами проблемы. и приходится искать DBA (или консультироваться).

и потом разгребать это всё крайне трудоёмко: в 99% случаев надо перекраивать схему, а т.к. это тех-долг, всё откладывается в долгий ящик.
ну и концепция “код важнее данных” тоже бесит!