Вероятность появления нового клиента к БД примерно равна вероятности замены Postgres на другую СУБД. Возможно, но в реальности практически никогда не происходит.
Если к БД обращается более одного клиента, мы теряем управляемость транзакциями (в бизнес смысле), мы теряем управляемость кэшированием, мы теряем гибкость в управлении миграциями - это как минимум. Потери от перечисленных факторов намного превышают потери от необходимости делать пересчет в таймзоны на бэкенде.
В некоторых реляционных СУБД есть специфичные решения для работы с деревьями. В частности, я использовал ltree в PostgreSQL для Materialized Path — работает очень хорошо, GIST индекс решает проблему поиска по подстроке.
Вероятность появления нового клиента к БД примерно равна вероятности замены Postgres на другую СУБД. Возможно, но в реальности практически никогда не происходит.
Если к БД обращается более одного клиента, мы теряем управляемость транзакциями (в бизнес смысле), мы теряем управляемость кэшированием, мы теряем гибкость в управлении миграциями - это как минимум. Потери от перечисленных факторов намного превышают потери от необходимости делать пересчет в таймзоны на бэкенде.