Тут все залежить від того, що від Вас очікує той, хто дав завдання.

скоріш за все очікують нового гребця за недорого

резонно))))

2й вариант норм, чего нет. файл же никто больше не перезапишет

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

можно пример что должно быть в миграции?

Самый простой пример - есть таблица с нон-налл колонками a, b, c, d, e. И надо в нее запихнуть пару тысяч записей, у которых поля b, c, d, e - одинаковые, а поле а - разное.

Имея возможность написать на жс-е простой мап, который к массиву с полями "а" добавит константы b, c, d, e и сгенерит инсерт на скьюэле выглядит проще чем ручками дописывать в файл insert ... values <тут 100500 строк копипасты>

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

Подскажите, если во время работы API сервера на ноде, увеличивается потребление памяти с 200  до 500 мб, то это явная утечка? (все запросы stateless, в памяти сервера ничего не храниться из стейта)

Не обязательно

какие есть варианты диагностики? понять это норм или нет

Подключить метрики и посмотреть за пару часов/дней статистику по памяти

в миграции нельзя вызывать методы модели/querybuilder?

Неа. В призме ты делаешь схему БД, и она по этой схеме генерирует .sql файл миграции.

подскажите пожалуйста, при выполнении запроса вылетает ошибка The conversion of a varchar data type to a datetime data type resulted in an out-of-range value. Не пойму почему не принимает такой формат даты если перед этим запросом я выполняю другой и такой- же формат данных вносит все ок
Тут ошибка
Executing (default): insert into ETA_MARSHRUT_DOC(bta_documents_id, Executors_FIO_id, Executor_type, dateK_plan, isMainExecutors, eta_actions_doc_id, parent_id) values(962957, NULL, NULL, N'2020-06-01T12:32:32.572Z', 0, NULL, 1299197)

а тут с таким же форматом все ок выполняет
`Executing (default): update ETA_MARSHRUT_DOC set Executors_FIO_id = 262, text_rezolizii = N'Костянтин Бєліков -розглянути', dateK_fact = N'2020-06-01T00:00:00.000Z', text_rezolizii_executers = NULL where id = 1299197
Update success!`

извиняюсь что пишу не вашему вопросу, а в чем прикол вот так называть по разному столбцы? то некоторые в upper snake case Executors_FIO_id, другие транслитом text_rezolizii в нижнем регистре, в третьих isMainExecutors вообще camel case,   в четвертых сокращения dateK_plan непонятные))

хз, бд не моя, я просто к ней делаю коннект и выполняю нужные телодвижения

понял, сразу просто навеивает ощущения какой-то очень старой легаси системы)

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

поставив я значить eslint із airbnb-base, а він як давай в кінці кожного рядка такий "Expected linebreaks to be 'LF' but found 'CRLF'."
воно звісно виправляється командою "--fix", але чи не можна часом десь в конфігах це по дефолту відключити?
чи це просто я жму ентер якось не так і eslint хоче мене виправити?

ты просто на винде сидишь
на винде перенос строки - \r\n (CRLF)
а на линухе - \n (LF)
в конфиге это должно настраиватся