Vitsliputsli

Изменится, но не значительно. И дело не в сетевом лаге, это вообще другой вопрос, а в других расходах на запрос.
Не понял, почему здесь пишут про использование/не использование индекса, в вопросе вы пишите про обращение по id, это надеюсь primary key, а значит в любом случае у нас поиск по этому индексу. Скорее всего как primary key вы используете число (int, bigint и т.п.), а значит у нас индекс BTree (с hash там вообще будет печально с производительностью). Сложность поиска по BTree - это log(n), где n - это порядок дерева. Только вот сложность и производительность не сильно коррелируют. Ведь когда вы будете менять высоту дерева это не просто обратиться к другому адресу в памяти, это нужно как минимум узнать загружена ли эта страница и получить ее адрес. Все это очень усложняет выбор дерева, теоретически не ответишь, нужно смотреть реализацию в MySQL.

Как уже правильно написали, ваш вопрос больше не про связи, а про ограничения (связь у вас присутствует: message.user_id -> user.id). Чаще всего, для контроля целостности базы данных используют ограничения на стороне этой же базы данных. Вы можете сделать этот контроль и в приложении: в этом простом случае, при удалении записи в user нужно будет чтото делать и с зависимыми записями message и все это нужно будет описывать (а ведь связь может быть не прямая, но и через другие записи). Когда база разрастется, появится много новых и сложных связей, вам придется все это контролировать, причем если вы забыли добавить контроль нового элемента вы сразу можете и не заметить, что консистентность нарушена.
При определенных условиях контроль действительно переносят в приложение, но когда понимают чем рискуют, а выигрыш перевешивает. Но это не тот случай, добавить ограничение будет эффективнее.

Можно, но с умом. При невысокой нагрузке, база данных скорее всего простит вам это. При высокой относитесь к json как к обычной строке, т.е. без всяких индексов и поисков по параметру внутри json, максимум когда выборка уже сделана, можно попросить СУБД выбрать нужный атрибут. Как бы PostgreSQL не агитировал за json, поиск по его внутренностям всегда будет хуже по производительности.

Как удобно, так и храните. Брокер сообщений предлагают, потому что, это универсальный вариант, гарантирующий доставку (если, конечно, не в памяти он будет хранить).
Если данные уже лежат в классический СУБД, то есть резон там же организовать очередь и забирать из нее, не вводя дополнительный инструмент.
Т.к. инсертим батчами, то разумеется нужно делать инсерт из файла, это будет эффективнее. Т.е. готовите файл, и через какой-либо промежуток времени заливаете его. И, разумеется, только после заливки помечаете записи как обработанные.
Наверное, можно писать даже прямо в файл для заливки, если архитектура позволяет, главное проработать момент, когда начинаем писать в новый файл, чтобы записи не попали в старый, когда началась процедура заливки в ClickHouse.
Но, при этом остается момент: ваш заливщик умер, когда уже получил подтверждение от Clickhouse, что все записалось, но не успел зафиксировать это в очереди. Соответственно это нужно проверять.
Если у вас не только insert, но и update, то нужно усложнять архитектуру (заодно и решится выше указанная проблема), нужно удалять предыдущие записи для обновляемых.

Что значить "Надо их где-то хранить"? Эти данные будут использоваться далее, отдельно от описанного?
Если не будут, просто сразу пересылайте из сервера Go в сервер nodejs. Если, чтото и потеряется, то оно все равно утратит свою актуальность и придут новые данные.
Если будут использоваться, то зависит от того, как будет использоваться, вполне может и вообще классическая СУБД нужна.

У каждого сайта есть свой сервер, своя статика и своя база данных. И все эти сервера находятся далеко друг от друга.

Например XDCR.

Посмотрите в сторону мандатного контроля, это в первую очередь решения на основе SELinux, и основные СУБД их поддерживают.

В большинстве СУБД есть журнал транзакций. Кроме MS SQL, в PostgreSQL он используется для восстановления состояния с момента бекапа до момента сбоя. В Oracle сможете посмотреть что было, когда было и сможете обращаться к таблицам из прошлого обычным SQL. Но этот механизм имеет ограниченное время просмотра.
Поэтому лучше подобное решать не средствами СУБД.

Триггеры очень не очевидная вещь, поэтому если хочется в БД перетащить часть логики, то лучше сделать процедуру для этого.

Отсутствие значения (null) не будет использоваться при операциях со строками. К примеру, если вы будете считать среднее по столбцу, то такие строки будут отброшены, а если вместо null будет 0, то они будет учитываться и результат будет некорректен.
Поэтому выбирайте по-смыслу.