vreitech

Какой отечественный linux выбрать для веб-разработки?

Никакой. Для web-разработки абсолютно фиолетово какой у тебя Linux, отечественный или нет. И если нет какой то особой осознанной нужды в использовании именно отечественных изделий, то лучше держаться от них подальше.

https://www.postgresql.org/docs/current/sql-syntax...
соответствовать синтаксису идентификаторов.

Если кавычек нет, то предполагается, что без учета регистра. Грубо говоря, без кавычек - все в нижний регистр.
В данном случае, надо добавить кавычки вокруг имени пользователя:
CREATE USER "PolzaK" WITH PASSWORD

Но учитывай, что тебе и дальше придется всегда указывать кавычки. В противном случае,
ALTER USER PolzaK ...
Тоже самое, что и
ALTER USER polzak ...

select distinct on (created_at::date) created_at, value from tablename order by created_at::date, value desc;

СДСМ, учебники по сетям - до понимания.
Пока вы себе усложняете жизнь, а не упрощаете.

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

У коммутаторов нет WAN и LAN. Да, собственно и у роутеров их нет, у нормальных-то :) Эти сокращения - фантазия маркетологов, продающих соховский дишман.
OpenWRT - роутерная прошивка, что ей делать на коммутаторе?

Server=localhost

Чей локалхост? У каждого контейнера он свой. Тогда какой указывать? Оптимально - по имени.
https://docs.docker.com/compose/networking/

Reference containers by name, not IP, whenever possible. Otherwise you’ll need to constantly update the IP address you use.

Port=6002

Чья туфля порт? Внутри докер-сети (Вы же указали: networks>postgres-network) контейнеры общаются по внутренним портам (рекомендуется).

Если резюмировать, то будет примерно так (поправить местами при необходимости):

"Postgres": "Server=localhost; Port=6002; Database=post; User ID=postgres; Password=passwd; Pooling=true"

"Postgres": "Server=postgres_db; Port=5432; Database=post; User ID=postgres; Password=passwd; Pooling=true"

docker-compose.yml:

version: '3.8'

networks:
  postgres-network:
    driver: bridge

services:
  gchain.posts.api:
    image: gchain.posts.api
    build:
      context: .
      dockerfile: GChain.Posts.Api/Dockerfile
    ports:
      - "80:8080"
    networks:
      - postgres-network
    depends_on:
      - postgres_db

  postgres_db:
    container_name: postgres_post
    image: postgres:latest
    environment:
      POSTGRES_USER: ${POSTGRES_USER:-postgres}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD:-passwd}
      POSTGRES_DB: post
    volumes:
      - postgres-data:/var/lib/postgresql/data
    ports:
      - "6002:5432"
    networks:
      - postgres-network
    restart: unless-stopped

volumes:
  postgres-data:

HDD - это расходники. Нет смысла обсуждать "меньше" или "больше" проживут. Сдохнут гарантированно. Если повезёт, то ещё в гарантийный период - бесплатно поменяете.

Для SOHO разница между линейками по большей части неважна. Вот что стоит уточнить - SMR или CMR диск и готовы ли с этим мириться. Достаточную ли вам предлагают скидку за террабайт, чтобы вляпываться в SMR. В одной и той же линейке дисков могут быть одновременно и SMR и CMR диски, уточнять нужно модели.
Далее, скорость вращения диска. 7200 чуть быстрее, 5400 медленнее но их попроще охлаждать в среднем. Различие скорости для личной медиатеки скорей всего неважно, но на достаточно хорошем интернет-канале торренты могут заметно озадачить массив количеством IO.

Зеркало будет надежно или лучше пожертвовать местом и сделать raid5 или 6?

Звучит как полное непонимание вопроса. Каким местом жертвовать, если именно зеркало даст меньше всего форматируемую ёмкость массивов? Местом придётся жертвовать, если делать как раз зеркало.
На примере шести 10ТБ дисков для удобства счёта, из 60ТБ RAW ёмкость массива:

raid0 или JBOD - дадут вам все 60ТБ, выпадение любого диска фатально.
raid1 - зеркало - даст вам как максимум 3 массива по 10ТБ, до 30ТБ форматируемой ёмкости. В каждом массиве соответственно можно потерять по соседнему диску. То есть хранилка выпадение одного любого диска переживёт, выпадение второго диска - смотря какому из дисков не повезёт. Можно потерять один из массивов полностью. (raid1 на всех 6 дисках вряд ли входит в вопрос, 10ТБ итоговой ёмкости, но чтобы их потерять из-за отказа диска нужно чтобы отказали все 6 дисков)
raid5 - даст вам 50ТБ форматируемой ёмкости. Переживёт выпадение одного любого диска, выпадение второго диска - фатально для всего массива.
raid6 - ближайший родственник raid5 - даст вам 40ТБ ёмкости. Но зато гарантированно переживёт выпадение любых двух дисков. Только отказ третьего будет фатален для массива.
raid10 - даст вам 30ТБ ёмкости как raid1, гарантированно выдержит выпадение одного диска, в идеале может работать на только половине дисков массива но критично зависит от структуры raid10, какие именно номера дисков могут быть потеряны без краха всего массива. Отказ второго диска может оказаться фатален. Используется не когда нужна ёмкость или возможность пережить несколько выпавших дисков, а когда нужна производительность, особенно на запись. То есть вряд ли ваш случай.

Что ещё надо упомянуть - вот диск из массива умер, сколько времени вам нужно это заметить, купить новый на замену, заменить? Плюс на таких объёмах займёт ещё сутки-двое-трое на восстановление массива. Вот тут причина, почему существует RAID6, хотя он по ёмкости хуже RAID5 и не лучше по производительности - пока у вас массив деградировал до 5/6 дисков, он переживёт выпадение ещё одного из дисков пока вы ставите замену и массив восстанавливается.

Тут всё просто. Про Mongo надо просто забыть. Это вообще не база данных, а бессмысленное хранилище по типу "куча мусора", которое используется исключительно в стильных модных молодёжных стартупах, в которых не нашлось ни одного специалиста по базам данных. Это была тупиковая ветвь, поднявшаяся на отсутствовавшей на тот момент поддержке JSON в базах данных и хайпе.

И вообще не надо называть "нереляционные хранилища" базами данных. Это специализированные движки - кэширующие(редис, мемкеш), поисковые(мантикора, эластик), аналитические (кликхаус) - которые используются в дополнение к базе данных. или совсем уж какие-то специализированные решения для визуализации или логирования- графана, сентри, кибана, локи - тысячи их. Но все это вещи факультативные, которые понадобятся только на определенном этапе развития проекта (или не понадобятся вовсе).

А с базой данных и её построением придется столкнуться с самого начала. И вот про это есть великолепная книга Святослава Куликова Реляционные базы данных в примерах. Она очень четко рассказывает именно про постройку базы данных.