Saboteur

Как не будет хватать производительности, можно будет задуматься. Но 300 это вообще не объем

Ну так клиентом комнадной строки дропай
psql -h 192.168.1.1 -d %dbname% -U %dbuser% -c "delete from users;"

или отдельный sql файл сделай со всеми командами и -f file.sql

Вопрос задан как пальцем в небо.
Быстрее будет не отдельно взятый постгрес или сайт на js, а машина, на которой это все будет считаться.
JS где - у пользователя в браузе, или это nodejs на сервере?
постгрес крутится на той же машине, или на другой? Какой там процессор, сколько, сколько памяти?

Не забывать, что если данные лежат в базе, а считать вы будете в JS, то к расчетам еще добавить время на передачу данных, поэтому чисто теоретически наверное выполнить все на постгресе должно быть быстрее.

Но вам никто не ответит на вопрос точно. Гораздо проще провести перформанс тесты и посмотреть живые ответы.

SSD - это расходник. Давно уже нужно понимать, что в 99% случаев, жизнь SSD более чем достаточна, особенно для "базы для личной разработки". Возьмите нормальный SSD на терабайт, и он переживет HDD

Есть БД на 1ТБ, создана искусственно. содержит кучу табличек с текстовыми полями содержащими хеш от рандома (каждая порядка 10Gb).
Копирование всего кластера на соседнюю машину занимает порядка 14 часов.

1 тб = 1000 гб.

100 мбит = ~10 мегабайт в секунду. 600 мегабайт в минуту То есть 1000 гигабайт/ 0.6 = 27 часов.

1000 мбит = ~100 мегабайт в секунду, но часто пропускная способность дисков упирается в примерно 50 мегабайт/сек = 3 гб/мин, 1000 гигабайт/ 3 гб ~ 5.5 часов

Подозреваю, что все-таки бутылочное горлышко либо сеть (gzip сжимает данные, потому вместо 27 часов получаете около 14)
Либо gzip сжатие в один поток (напрягается только одно ядро, из-за чего кажется, что CPU не нагружен), выполняется слишком долго.

В первом случае убедитесь, что -z включено и попробуйте -Z 9, а также гигабитную сеть
Во втором случае попробуйте наоборот -Z 1, чтобы уменьшить нагрузку на CPU

Так вам нужно много табличек.
Табличка с типами заданий, табличка с ключевыми персонажами, предметами, строками которые фигурируют в задании. Табличка с самими квестами, где для квеста будет перечислены его шаги из заданий и участников, логика квеста (его ветки в зависимости от результата выполнения) а также известный ревард.
А уже потом табличка со статусом пользователей о прохождении конкретного квеста.

alejandro@node:~$ sudo -i -u postgres
[sudo] password for alejandro:

Тут же черным по белому пишет, что пароль запрашивает команда sudo, а не postgres
либо настройте sudoers так, чтобы для вашего пользователя ваш пароль не запрашивало, либо логиньтесь от имени пользователя postgres, или вообще разберитесь с аккаунтами и вашими целями.

"1) Добавить транзакцию - всего несколько строк кода.
2) Как раз таки хотелось бы услышать, какие кейсы проблем здесь возможны"

Написать несколько строк кода - время разработчиков и деньги заказчика."
Протестировать несколько строк кода - время тестировщиков и деньги заказчика.
Добиться создания новой таски, которую оплатит заказчик - время менеджеров и деньги заказчика

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

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

IMHO ваша нагрузка вообще невелика. У меня на mysql живут проекты с несколькими миллионами добавлений в сутки, и я не считаю, что это едва середнячок.

MySQL все еще считается более популярным и в случае чего, проще найти для него ответы. Для вашего проекта я бы порекомендовал его.