Реляционная модель хорошо выражает бизнес-инварианты: заказы, права доступа, связи между сущностями. Ограничения целостности и внешние ключи помогают не накапливать «немые» данные, которые потом дорого чинить скриптами.
Проектируем индексы под реальные запросы, а не «на всякий случай», и следим за планами выполнения на росте объёма. JSON и JSONB используем точечно — когда гибкость структуры оправдана, но источник истины по-прежнему осмысленно нормализован.
Схема живёт в миграциях в репозитории: это обязательное условие для командной разработки, воспроизводимых окружений и откатов. Бэкапы, репликация и целевой RPO/RTO обсуждаем до запуска, а не после первого инцидента.
При необходимости PostgreSQL сочетаем с Redis, поисковыми движками и очередями — каждый слой решает свою задачу, не дублируя роль основной БД без явной стратегии.