Сразу оговорюсь: практического опыта в ПГ у меня нет. В СУБД опыт - это, в основном, Oracle (больше 15 лет).

Примерно полгода в фоновом режиме читаю документацию, форумы/хабр/стэковерфло и т.п.
Познакомился с особенностями:
- типов данных (типа timestamp vs date vs timestamptz, text vs varchar, number vs integer, empty string vs null и т.п.)
- временных таблиц (можно считать, что их нет)
- транзакционный DLL
- ПГ это версионник (грубо говоря - частые update больших/широких таблиц - это плохо)
- зависимости объектов не дают менять определения типов таблиц, и вообще "связывают" по рукам и ногам (см. ниже *)
- отсутствие автономок
- отсутствие пакетов, но зато есть схемы (и схема <> пользователь)
- ну и прочее.

Я планирую примерно такую "архитектуру" БД:
- на нижнем уровне - таблицы, прямого доступа к таблицам у "людей" не будет
- уровнем выше - представления, с фильтрацией удалённых (архивных) записей + что-то типа RLS своими руками + instead-of триггеры для протоколирования и замены delete на mark_as_deleted
- выше - функции и другие представления (отчёты и т.п.)
- объекты для бизнес-логики - в одних схемах, объекты уровня API - в других
- конечно возможны исключения, но они не должны носить массовый характер.
Трехзвенку не хочу (да и не потянем мы).

С БД будет работать несколько приложений, их много но принципиально выделяются следующие:
- загрузчики данных (write only)
- читатели данных (read only)
- админы, менеджеры (и другие сотрудники бизнеса) системы - в основном десктопные пользователи
- "случайные" пользователи сервиса - это веб-пользователи личного кабинета

Соответственно для каждого приложения будет отдельная учётная запись, а "люди" авторизуются дополнительно по логину/паролю[/коду подтверждения].

Нагрузка на БД со стороны "людей" - мизерная, поэтому протоколирование планирую делать на лету в instead-of триггерах.

(*) - ПГ по зависимостям автоматически не перекомпилирует объекты, поэтому при разработке таблиц сразу уделяем максимум внимания к типам данных и именам. В процессе развития системы в существующие таблицы разрешаем только добавлять новые столбцы. Переименование (удаление) таблиц/столбцов или изменение типов данных на проде - это значит остановка сервиса, хоть и кратковременная.


Прошу критики к тому, что выше.

И вопрос: есть ли практическая польза в доменах?
Я пока только увидел одну "полезность" - check constraint на текстовое поле. И то его можно делать и без домена.
Остальные поля - даты, числа, логические - они меняться не будут (т.к. см. выше *).