Причём тут это? Если речь про эти системы, то там, конечно современные бэкендеры не нужны.

мы же говорим о выборе той или иной системы программирования, и да во многих ситуациях действительно современный бекендер - излишество, проще взять полуфабрикат и сделать системы в зрелом стеке без когнетивного разрыва JAVA\SQL

либо выстраивать архитектуру и процессы с чётким разделением труда, мухи отдельно котлеты отдельно

проблема пхп в том, что по мере роста количества запросов они все довольно быстро начинают дорожать

С позиций своего практического опыта (и больших и малых проектов) - не вижу никакого "когнитивного разрыва" между Java, которая на бэкенде (springboot. quarkus. jee, etc.) и SQL. Это успешно делают одни и те же люди, на рынке их достаточно. Никакого специального тайного знания, недоступного java бэкендерам, работа с современными СУБД не требует, тем более что в проекте используется как правило какая-то одна.
А что такое "зрелый стек", если java/sql это "незрелый" - это oracle forms?

Это в мире энтерпрайза возможно. В остальном есть фулстак, он же DevOps, он же DBA, он же еще кто-то :)

Ну когда подорожают, можно будет подумать над микросервисами на Go или Node. Пока до этого очень далеко

Промышленная разработка по имеет свою точку окупаемости, это да. Но обычно при переходе от "два пацана в гараже пилят поделие" к "делаем сверхважную штуку" переход доступа резкий.

Если есть понимание того, когда оно свершится - дело можно строить удобным образом.

Которые запросы? http? sql? и почему? оверхед на поднятие процесса или что имеется ввиду

Я не знаю таких джавистов которые могли бы одинаково хорошо владеть различными диалектами SQL в приложениях ОЛАП и ОЛТП, крайне мало вообще понимают разницу между кластерным индексом и IOT, не видил ни одного кто бы адекватно мог оценить планы с прома и репродьюсноть данное состояние на деве. Поэтому максимум что может массовый джавист прочитать реляционную модель, строкой написать сиквел и сбиндить переменный, как только включается массивный паралеллизм через пулы, инвалидация кешей данных на беке... малина заканчивается. Я уже не говорю об адекватном тестировании катастрофоустойчивости всяких там миграций и тд.

хорошие разрабы баз вполне комфортно переучиваются с вертики на терадату, знают и умеют работать с RAC кластерами, понимают зачем инверсный индекс. Это другой мир.

Да не, нормально сочетается )

Это ты про что?

Ну, у меня вокруг таких десятки )

Вёзет)))хотя не верится...

Как сказали, один едет по встречке?! Да тут их сотни !!!  😊

каких джавистов взяли такие и есть. у меня другие

где ж их добывают )))))))))))????

Сложный старый продукт вокруг Oracle. Логично, что все разработчики, которые давно работают - хорошо понимают в внутренностях.
На самом деле ничего особенного сложного в SQL и реляционных БД нет, не понимаю, откуда такие проблемы.
Да, обычно диалект конкретной БД приходится доучивать (но это быстро). В тонкости настроек тоже лучше погружаться DBA (благо поддержка DBA стоит недорого). Но корректно проектировать и нормально писать код (включая сложные транзакции) - вполне получается.
Понятно, что ребята из DataEgret или PG Pro многие запросы напишут лучше (особенно сложные), но это уже совсем другой уровень.