«В карантин нагрузка выросла в 5 раз, но мы были готовы». Как Lingualeo переехал на PostgreSQL с 23 млн юзеров

Режет — это нормально. Для кого-то и первый SQL после dbase или QBE мог взорвать мозг. Но к тысячному SQL ничего уже резать, возможно, и не будет)

«В карантин нагрузка выросла в 5 раз, но мы были готовы». Как Lingualeo переехал на PostgreSQL с 23 млн юзеров

Вы описали мир, в котором еще не придумали тесты и термин «DBA» применяли ко всем, кто знает SQL. Действительно, адский мир. Хорошо, что не наш)

«В карантин нагрузка выросла в 5 раз, но мы были готовы». Как Lingualeo переехал на PostgreSQL с 23 млн юзеров

У нас с десяток таких схем, в каждой, скажем 10 файлов по 5-10 хранимок. Вроде удобно

«В карантин нагрузка выросла в 5 раз, но мы были готовы». Как Lingualeo переехал на PostgreSQL с 23 млн юзеров

У нас с десяток таких схем, в каждой, скажем 10 файлов по 5-10 хранимок. Вроде удобно

«В карантин нагрузка выросла в 5 раз, но мы были готовы». Как Lingualeo переехал на PostgreSQL с 23 млн юзеров

> база не должна заниматься парсингом входящего запроса и генерацией готового вывода

Вы совершенно правы! Парсить POST и генерить в ответ HTML или JSON вполне может некий универсальный прокси. Но он как-то будет при этом общаться с БД. И тут, внезапно, оказалось, что для обмена прокси с БД можно использовать JSON и этот прокси практически не нужен. Ну его и убрали, что тут плохого? Будет нужен SOAP — вот тогда и допилят прокси XML <-> JSON. Это не сложно, я проверял)

«В карантин нагрузка выросла в 5 раз, но мы были готовы». Как Lingualeo переехал на PostgreSQL с 23 млн юзеров

Полагаю, «в последние 5 лет подрос» — это не про хранимки, а про поддержку JSON. Потому что биллинг для телекома на хранимом коде PG вполне успешно писали и в нулевых. И да, он еще в продакшене)

«В карантин нагрузка выросла в 5 раз, но мы были готовы». Как Lingualeo переехал на PostgreSQL с 23 млн юзеров

Вы же пишете, что у PG все отлично с JSON. Значит и сматчить внутри БД не проблема.
В этом случае можно не только загрузить код в БД, но и прогнать все его тесты в той же транзакции. Не думали об этом?

«В карантин нагрузка выросла в 5 раз, но мы были готовы». Как Lingualeo переехал на PostgreSQL с 23 млн юзеров

Может, такие способы не показывают потому, что они слишком просты?)
Скажем, есть у нас папка, в которой лежат исходники всех хранимок некоторой схемы БД (вроде account/create.sql и т.п.) и там же файлы с их тестами.
Как делать миграцию? Удалили схему и в одной транзакции накатили все файлы. Если тесты пройдут — делаем коммит. Это удобно или это с костылями?

«В карантин нагрузка выросла в 5 раз, но мы были готовы». Как Lingualeo переехал на PostgreSQL с 23 млн юзеров

Не стоит ли в этой формулировке заменить «Python» на «любой нехранимый в БД язык»? Это же глобальное деление — операции с данными, в основном, стоит положить в БД, а остальные — нет. К примеру, рассылку почты лучше делать не хранимым языком, не так ли?

Параллельные интеграционные тесты базы данных Postgresql в приложении GO

На практике миграцию мы делаем так —
1. BEGIN;
2. Удалить схему со старым кодом
3. Создать схему с новым кодом
4. Прогнать тесты нового кода
5. При успехе — коммит

Правда, у нас параллельность не очень актуальна — 300+ тестов проходят за пару минут, делаем подряд

Параллельные интеграционные тесты базы данных Postgresql в приложении GO

А почему бы не выполнять каждый тест в своей транзакции? В этом случае
1. не надо менять имя схемы
2. можно гонять тесты и на боевой БД
3. можно гарантировать, что код в БД поменяется только при успешном прохождении тестов