Есть ли исполнитель или плагин для DuckDB?
Нет, и это осознанно. DuckDB поставляет CLI одним бинарным файлом, который уже делает работу, поэтому Dagu запускает его как обычный командный шаг. Отдельный исполнитель добавил бы лишь слой, который нужно синхронизировать с релизами DuckDB, давая меньше, чем даёт сам CLI.
Как не дать двум запускам повредить файл базы?
Установите max_active_runs в единицу на уровне рабочего процесса. Ещё идущий запуск блокирует следующий по расписанию вместо открытия второго писателя — это декларативная версия lock-файла, который документация DuckDB предлагает построить самостоятельно. Правило действует только на запуски этого процесса, поэтому другие процессы держите подальше от того же файла.
Что происходит, когда большому запросу не хватает памяти?
Задайте resources.limits.memory на уровне рабочего процесса, чтобы запуск был ограничен до того, как утянет хост, и добавьте шагу политику повторов для временных, а не структурных сбоев. Запрос, которому нужно больше памяти, чем есть у хоста, следует переписать, а не повторять.
У DuckDB есть расширение cron от сообщества. Почему не использовать его?
Оно планирует внутри процесса DuckDB, поэтому расписание существует лишь пока живёт этот процесс. Нет ни истории запусков, ни повторов, ни оповещения об ошибке, ни чего-либо, что можно посмотреть наутро. Это подходит долгоживущему встроенному приложению, а не пакетной работе на сервере.
Может ли DuckDB читать из S3 в запланированном запуске?
Да, через расширение httpfs — именно так большая часть запланированной работы с DuckDB читает Parquet без отдельного шага извлечения. Поскольку объектное хранилище является сетевой зависимостью, именно этому шагу стоит задать политику повторов.