Melkij

create table aggregate_montly (
    user_id bigint not null references users(id),
    month date not null check (date_trunc('month', date_period) = date_period),
    orders_count bigint not null default 0,
    -- прочие предаггрегированные данные
    primary key (user_id, month)
);

Дату писать всегда как первое число месяца, check constraint гарантирует, что вы не запишете по ошибке данные за 8 февраля вместо месяца.
id выкинут за бессмысленностью. Тем более uuid.

Не уж то postgres нужно так много журналов хранить?

А то что перенесено куда-либо через archive_command самому postgresql вообще не нужно и база об этих файлах никак не беспокоится. Это нужно тому, кто это настраивает. И в ведении как раз этого человека и будет вопрос "сколько валов нужно хранить".
Если тот кто настраивал archive_command тоже не беспокоится об архиве - то архив будет бесконечен (16 EiB, это не шутка).

Архив wal нужен для pitr (или file-shipment replication). Для pitr нужны абсолютно все wal без исключения с момента снятия basebackup до требуемой точки восстановления (при том точка восстановления не может быть ранее времени окончания взятого за основу basebackup). В каких временных рамках вам нужен pitr - выбираете соответственно при определении собственной же политики требований к бекапам.
(10гб места под бекапы звучит откровенно поразительно, если у вас настолько маленькая база - то зачем вам 80гб основной диск? И 8 было бы много)

А как? Ну вот прямым текстом: как это в принципе и в теории возможно сделать без участия приложения?

begin isolation level repeatable read ;
select ... from users;
-- а дальше-то что?

Окей, begin действительно можно отсрочить до прихода следующего запроса, но вот абсолютно никак не позже запроса select вы обязаны решить, отправлять эту транзакцию на реплику либо на мастер. Как вы это определите? С равной вероятностью следующей командой может быть commit, другой select или пишущий запрос. Вы это никак не можете узнать, но вам уже необходимо эту транзакцию отправить куда-то и получить результат. И ровно так же вы не можете отправить запрос сначала на реплику, а запись потом на мастере потому что у вас развалится снэпшот транзакции.

select * from calculate_user_rating(423);
А это читающий или пишущий запрос? Да этого сама база не знает! Хрен его разберёт, что этой pl/python хранимке на непонятном для базы языке вздумается делать.

Репликами должно уметь пользоваться само приложение. Кроме самого приложения больше никто не знает, допустимо ли запрос отправлять на реплики и если да, то на какие именно

• перепроверяете, что СУБД остановлена и не запущена
  
• находите datadir (например, /var/lib/mysql/ )
  
• ставите на рабочей системе mariadb (или mysql - выясните, какая именно была установлена) той же самой версии
  
• копируете целиком всё что есть в datadir в новое место жительства
  
• запускаете СУБД и смотрите в лог
  

The client was disconnected by the server because of inactivity. See wait_timeout and interactive_timeout for configuring this behavior.

Ммм, вполне простой английский. Гуглопереводчик справляется на ура, я даже специально проверил.

mysql устал ждать от вас команд и закрыл соединение, которое считает сообразно своим настройкам никому не нужным.

select ... from regions 
where id in (
    select j::int 
    from tokens cross join json_array_elements_text(regions) as j 
    where user_id = 5
);

Функции и операторы json в postgresql явно реализовывались под объекты и возможностей по работе с json массивами чисел порой не хватает.
А потому приводим вручную к числу.

Можно ли так сделать?
Ну и так же вопрос, могу ли я пару сайтов разместить внутри контейнеров?

Можно.
Это чисто настройки сетей вопрос.
Начните вот отсюда: https://wiki.debian.org/LXC/SimpleBridge
Скорей всего у вас один ipv4 и потому интересует настройка бриджа без добавления в него физического интерфейса основной системы + настройка NAT для трафика проходящего от моста.
Для размещения видимых извне сервисов добавляются правила перенаправления входящих пакетов (например на 443 и 80 порты) на внутренний IP этого виртуального bridge.

Это бывает неожиданностью, но совершенно верно, размер файловой системы не обязан совпадать с размером раздела.
resize2fs меняет размер только файловой системы. После этого необходимо изменить размер раздела. parted умеет команду resizepart. Про cfdisk не в курсе.

При том, при уменьшении раздела будьте предельно аккуратны. Как и многое с правами root, система разрешит вам сделать размер раздела меньше чем файловая система. С фатальными последствиями для файловой системы.
Неплохой идеей будет сначала подрезать размер файловой системы сильнее, чем предполагается (до 7,5гб, например), уменьшить раздел, затем выполнить вновь resize2fs без явного указания размера что увеличит размер ФС до размера раздела. Так будет гораздо ниже риск того, что где-то ошиблись (например, в единицах измерения килобайты либо кибибайты) и отрезали часть файловой системы

проверку на лишние ключи, так же на пустые строки и на тип данных в ключах (должна быть строка).

Сделать шаг назад и задать вопрос "а зачем я здесь пытаюсь прикрутить JSON вместо более простых, компактных и быстрых plain полей"

jsonb_typeof для типа данных в JSON, для проверки "только такие ключи" сходу даже затрудняюсь что-то найти подходящее для check constraint.

select current_date,
current_date - interval '6 day',
date_trunc('month', now()),
now();

Просто другой набор функций, выберите подходящую.

иногда есть фризы, например, если открыть пхпшторм, который я уже 2 часа не открывал, или резко перейти с него на фотошоп

Внимательно посмотрите на свой swap.

Процессору глубоко фиолетово на переключения активных задач. У него и так постоянные смены контекста по много тысяч раз в секунду. Потому что даже системных процессов запущено больше чем существует ядер.

Его написал мой коллега https://github.com/kamranahmedse/roadmap.sh/pull/196 Алексей Лесовский после сбора фидбека со всей нашей команды DBA. Так что вряд ли раскритикую год спустя.

"конца" у roadmap нет. troubleshooting и optimization бесконечны. А уж тем более необъятна hackers тематика.

Если заходить со стороны разработки - создайте маленькую базу неважно какой тематики (да хоть q&a сервиса), заполните сгенерированными данными гигабайт на 10-100 и заставьте это шевелиться за вменяемое время под синтетической нагрузкой (хоть pgbench). А потом начните менять схему данных, не останавливая нагрузку. А потом восстановить базу на состояние до миграции из бекапа.