Тоже не понимаю. Взять хотя бы какое-нить трезвенное приложение. 1) СУБД, 2) апп сервер, 3) клиент. Если вдуматься , то на первых двух звеньях выполняется одни и те же действия. описываются какие то структуры данных и операции над данными, дальше выполняются какие действия в терминах этого описания.

Эта схема возникла эволюционно. До недавнего времени архитектура была оправдана , поскольку надо было хранить (и организовывать) большие объемы данных, которые помещались только на диск, ОЗУ было дорогое и маленькое (даже в плане адресации). СУБД до сих пор многими воспринимается как какой-то продвинутый аналог физ устройств хранения.

Но ведь ситуация меняется. СУБД может обрабатывать данные, 512 ГБ ОЗУ на сервере - вполне достижимо даже при небольших затратах. И в этих новых реалиях возникает ощущение, что старая архитектура стала сильно избыточной. Ну в самом деле, данные поднимаются с диска в кеш СУБД (эти процессы идут внутри СУБД), а оттуда тащатся в память апп сервера (его взаимодейстия с СУБД). При этом процесс организован, как правило, страшно неэффективно. Я, например, встречал исследование, когда открытие форм приводит к тысячам простых запросов к СУБД, а ведь каждый запрос надо отправить, передать, принять, распарсить, построить план, проверить доступы, выполнить (при необходимости поднять данные с диска), и всё это - что бы отправить маленький кусочек данные обратно.

MSSQL 2014, например, декларирует что стал сильно быстрее за счет in-memory. Проблема в том, что в старой архитектуре тысячи простых запросов никуда не деваются. Ускорение достигается только за счет этапа "при необходимости поднять данные с диска" - и всё.

В общем вопрос - что сейчас мешает использовать СУБД как единственный серверный компонент, совмещающий возможности СУБД и апп.сервера? Я не имею в виду инерцию мышления (это понятно). Хочется услышать про другие причины, любые, кто как видит.