rPman

имена переменных бери из строки:

const connectionString = `postgresql://${process.env.POSTGRES_USER}:${process.env.POSTGRES_PASSWORD}@${process.env.POSTGRES_HOST}:${process.env.POSTGRES_PORT}/${database}`;

Хост у тебя судя по скрину - localhost, в крайнем случае используй то что возвращает консоль по команде hostname

чтобы понять что происходит, назначение ключей psql смотри в документации или по команде psql --help
p.s. смотри внимательно сообщение об ошибке
в особо извращенных случаях сервер может быть не локальным, а его адрес прописан у пользователя в домашнем каталоге в .pgpass или pg_service.conf

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

Если удобного идентификатора нет, то обычно самое простое, - формировать из сравниваемых данных строку одинаковым способом, и получать из нее хеш сумму (md5 более чем подходит, если данных не 16-значное количество, т.е. не нужно заботиться о коллизиях), его и используй как идентификатор и храни где-то списком как предыдущие значения и сравнивай с ново загруженной, прямо во время анализа. Записи, хеш сумма которых, не была найдена в записях, помещай в базу данных (ну или обновляй значения, если речь идет о модификации а не добавлении новых).

Нормальный разработчик не будет хранить пользователей проекта (особенно если у него пользователей много) в памяти, а воспользуется для этого базой данных

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

Скорость чтения максимально просто сериализованного массива (например строка с разделителем) из десятков и сотен значений значительно превышает запрос на поиск таковых в базе данных.

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

Да, параметризовать можно только значения но не наименование полей и таблиц (мало того ты и prepared запрос так не сможешь сделать, с каждым новым значением $(column) будет новый запрос).

Да, тебе придется валидировать значение в $(column) но это не сложно так как там допускаются только латинские буквы (оба регистра), цифры и подчеркивание. Конечно если ты не используешь идентификаторы_в_ковычках (там любые символы, но зачем тебе стрелять себе в ногу), ну в крайнем случае как разработчик ты знаешь что у тебя в запросе и какие допустимые наименования полей там могут быть

Зачем ты 7 раз запускаешь бота с одним и тем же портом?, слушать он сможет только один (точнее один на каждый локальный ip адрес).

Чтобы ничего не выводилось пиши .on('error',()=>{}) но толку то от этого, оно в любом случае не сработает, это просто уберет вывод сообщения об ошибке

nodejs полностью асинхронный, когда ты вызываешь метод, помеченный async (при вызове не надо писать await) то в любой момент когда в этом методе вызывается асинхронный метод или стоит await, node будет вываливаться в свой главный event loop и обрабатывать другие запросы

ты спокойно пиши свой setTimer, внутри вызывай свой метод без await (он должен быть помечен как async) и все должно красиво работать, везде где это возможно либо заворачивай в async метод, либо работай с promise либо пользуйся готовыми асинхронными методами

В необходимость правильного использования базы данных тебя уже "ткнули носом", повторять не буду.

Но если прямо очень хочется работать с файлами (а иногда это оправдано, например при монопольном однопользовательском доступе к данным) то совет, не храни 100500 данных в одном файле, создай каталог и внутри на каждый объект создавай json файл, с именем - идентификатор этого объекта

такая key-value база данных простая, удобная, быстрая, подходит там где sql это излишне. Иногда поверх этого делают индексы (файл в котором фильтруемым данным сопоставляется список id) но если возникает такая необходимость лучше все же задуматься о нормальной базе данных
-------------------

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

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

Файлы! С доступом как статика на веб сервере, при необходимости права разруливать через basic auth (само собой https обязателен), добавляя пароли в url. При БОЛЬШОМ количестве файлов и сложной структуры по их управлению, заводи в базе данных прослойку а имена файлов пусть будут завязаны на идентификаторы из этой базы (или как некоторые делают - хеши от содержимого, как бонус дубликаты отлавливать)

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

В конечном счете все решает стоимость решений

Выделенный сервер (dedicated server upd или bare metal) - это буквально физический сервер, мощности которого принадлежат тебе и твоим программам
Виртуальный сервер (virtual private server) - это когда физический сервер делят на части и продают по отдельности, что сильно дешевле, и удобнее хостеру (он может перекидывать виртуальные машины между физическими, оптимизируя нагрузку), мало того он может оверселить, продавая и обещая больше мощности чем доступно в среднем, надеясь что пиковую нагрузку сервис клиента будет давать редко а остальное время она будет низкой (так обычно и бывает), такие машины обычно самые дешевые (когда видишь предолжения ниже ~30$ это оно самое)

Кстати нормальная практика даже для dedicated server жесткие диски заменять на NAS например iscsi, а реальный диск предлагать как опцию. Сетевые накопители обычно медленней но сильно дешевле для хостера, так как их так же можно делить, снапшотить (например за их счет делать дешевый бакап) и оверселить (а главное централизованное обслуживание, так как диски чаще всего выходят из строя).

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

Но нужно понимать что фишки гибкой конфигурации даются не бесплатно и если у тебя постоянная нагрузка, VPS оказываются дороже dedicated server. Правильный подход кроется в комбинировании.

И еще одна услуга у хостеров - предоставление не сервера а услуги - доступа к програмному обеспечению по какому то внутреннему алгоритму тарификации (Software As A Service). Например можно приобрести услугу http сервера (или к примеру хостинг nodejs бакэнда, отдельно базы данных, сервиса бакапов и т.п., такие точно есть), без покупки самой машины, с тарификацией по запросам, трафику или по внутренним cpu тикам, при этом пользователю не важно, сколько там в реальности задействовано серверов, хостер будет обеспечивать заказанный трафик с обещанной скоростью, только плати. Такие крупные провайдеры как гугл или амазон могут встраивать в свои прайсы на такие сервисы ловушки, не изучив и не подготовившись как следует к которым можно попасть на значительное повышение стоимости, к тому же часто такой доступ еще и привязывает клиента к конкретному провайдеру, так сильно что когда придет известность и нагрузка, может не получиться легко сменить хостера на более оптимальный.