Melkij

Мы делаем ежедневный отчёт кроном, после формирования которого вызываем pg_stat_statements_reset. То есть раз в сутки.

Прежде чем пытаться изобрести колесо - проверьте штатные возможности. Если вам ну прямо так очень хочется использовать uuid вместо более компактного и быстрого bigint - то такой тип данных уже есть в postgresql.
Хранится как фиксированной длины поле 16 байт.
Преобразованием его в bytea вы только увеличите, а не уменьшите его размер. Т.к. для bytea потребуется хранить ещё длину данных в этом поле.

С постгресом пока что на Вы и не могу понять что он от меня хочет.. Как я понял из интернетов он плохо воспринимает бинарник в UTF'е

В смысле так и задумано. Если у вас база в utf8, то все текстовые поля намеренно проверяются, чтобы в них было что-то валидное для utf8.

permission denied for schema public

Кто-то явным образом сделал
revoke create on schema public from public;
Это право дефолтное для public схемы, его именно кто-то или что-то намеренно отозвал.

соответствующий grant
grant create on schema public to username

Увидел 3 ответа, ну думаю, элементарно, ответили уже. Но зачем так сложно?
group by field_name is null
всё. Группировка по выражению, зачем его делать строкой в подзапросе или числом? bool самого по себе более чем достаточно.

Потому что SQL - это троичная логика. true, false и NULL: https://www.postgresql.org/docs/current/functions-...

null != что угодно - будет null в результате.

select count(*) filter (where status = 'active'),
count(*) filter (where status = 'offline') ...

наиболее оптимально

не делать count вовсе.

where exists(select from jsonb_each(variants) where (value->>'price')::numeric between 0 and 10);

Судя по желанию делать бекап удивительно часто - вы пытаетесь найти PiTR.
В целом: https://www.postgresql.org/docs/current/continuous...
В частности: wal-g, barman, pgbackrest чтобы не собирать конструктор вручную.

Ооо.... Вы это сейчас вообще серьёзно?

Если вы запускаете DBaaS платформу и не знаете что делать собственно с базами - то у вас не

Запускаю свою облачную платформу, код и архитектура создана с нуля.

У вас нет вообще абсолютно ещё ничего и уж архитектуры - в особенности. Кроме "идеи", над которой бьётся давно и много кто, при том имея ресурсы на собственные команды DBA.

Например: юзер пишет какой-то запрос и ему не нужно указывать на какой сервер что отправлять или откуда читать, для него это один сервер.

Значит этому юзеру достаточно ходить только на мастер.
Для сферического в вакууме приложения нет средств автоматически распределять запросы по репликам. И такое сделать вовсе невозможно без накладывания ограничений на использование. Например,
select somefunc();
Что делает эта функция? Она только читает данные и потому можно отправить на реплику или она пишет и потому должна быть на мастере? Хотите правильный ответ от контрибьютора postgresql? Это достоверно не знает даже сама база до тех пор пока не выполнит функцию.

Другой пример:

begin isolation level repeatable read;
select ...
update ...
commit;

Как максимум на запросе select вы должны уже знать можете ли вы эту транзакцию отправить на читающую реплику. Откуда бы вам это узнать заранее?
И прочие принципиально-нерешаемые вопросы.

DBaaS это не про большие базы. Как бы не хотелось маркетингу убедить в обратном. Это про небольшие или стартующие проекты, где проще переплатить сервису за относительно вменяемую настройку и сопровождение типовой конфигурации.

select distinct on (price_id), price_id,value  from tablename order by price_id, time_action desc

Если на каждый price_id много строк - то вы неверно думаете что запрос замедляет.

select price_id, value from prices as t1 lateral (select value from test t2 where t1.id=t2.price_id order by time_action desc limit 1) on true;

Если таблицы prices нет - то сооружать loose index scan вручную.
Всё разумеется с подходящим индексом.

А смысл говорить про права если вы даже не подключились к базе?

Хотите просто и не разбираться с правами - от postgres и снимайте дамп. sudo -u postgres pg_dump ...