Hовости о PostgreSQL 12 / Олег Бартунов (Postgres Professional) 

А размер индекса? GIST-индексы при постоянных обновлениях индексируемых полей имеют свойства сильно разрастаться в размерах, что требует регулярного их пересоздания или реиндексации. Если размер ОЗУ на сервере БД ограничен, то это может быть проблемой.

А для какого случая?

Я с о стороны Postgres, Mongo тоже смотрится необычно ;) P.S. 3 года назад дописал проект с JsonB, с функциональными индексами ;) Крайне удобно менять логику приложения, не используя DDL для базы ;)

ORM - для мелких проектов и презентаций. Серьёзные проекты не используют ORM, потому что его дорого и больно кастомизировть. Читабельность кода - дело вкуса. Мне, например, намного проще прочитать запрос, чем понимать, что там ORM делает, рыскать в логах в поисках сгенерированного запроса. Поддержка этих фич если и будет, то года через 3.

В официальной документации есть рекомендация по удалению внешних ключей при загрузке большого количества данных www.postgresql.org/docs/current/populate.html#POPULATE-RM-FKEYS Это справедливо и для highload систем, где обычно тоже обрабатывается большое количество данных (но в коротких параллельных транзакциях). Внешние ключи и другие ограничения целостности не бесплатны и влекут за собой некоторые накладные расходы (увеличение latency, например), которые могут быть просто неприемлемы в highload системах Не стоит воспринимать этот совет как истину в последней инстанции. Это компромисс между производительностью системы и целостностью данных

FK - это контроль целостности. Реализован он так, что при изменении значения PK в материнской таблице у тебя идут проверки во всех таблицах, связанных с ней при помощи FK. Иногда у тебя на PK какой-то одной таблицы типа "юзер" может быть навешано столько FK, что удаление строки в "юзерах" или смена в ней PK приводит к проверкам, длящимся несколько десятков секунд для каждой записи. Зачастую, в угоду скорости (и меньшему потреблению вычислительной мощности на сервере БД) проще удалить/изменить запись в "юзерах", а потом подчистить остальные таблицы уже асинхронно.

@@solarscorcher1566 FK в 99% это или autoincrement или uuid или тп. Смысл делать update этому полю = 0. Десятки секунд на удаление??? фантастика честно говоря. Если все так плохо, то не проще сделать soft_delete и уже асинхронно удалить пачку? Но остается проверка на целостность. Я бы согласился, если бы утверждение звучало так: "В некоторых случаях FK лучше не использовать" вместо "FK + highload = неправильно"