И Postgres даёт механизм, чтобы это реализовать.
Background Workers в Postgres — это процессы, которые работают внутри самого сервера базы данных. Не рядом, не «поблизости», а внутри него.
Типичный паттерн, который используют команды:
scheduler → приложение → база → логика в приложении → запись в базу
Приложение просыпается, проверяет изменения, обрабатывает их и записывает обратно. Пять переходов для задачи, которой не нужно было выходить за пределы базы.
Инструменты вроде
pg_cron построены на Background Workers. Задача выполняется как фоновый процесс внутри Postgres: читает состояние, выполняет логику, записывает результат — без участия приложения.Это не просто «ближе к данным».
Это когда данные сами обрабатывают себя.
Где такой подход выигрывает:
→ истечение просроченных резерваций
→ очистка старых строк
→ обновление производных данных
→ смена состояния записей
→ небольшие задачи обслуживания, завязанные только на локальные данные
Это не универсальный паттерн. Внешние API-вызовы, координация между сервисами, долгие воркфлоу, бизнес-оркестрация — остаются в приложении.
Но для небольших задач, завязанных на состояние и локальные данные — фоновый воркер внутри Postgres даёт более чистую архитектуру.
Проблема не в использовании cron.
Проблема в том, что задачи, связанные только с данными, выполняются далеко от этих данных.
Background Workers в Postgres позволяют это исправить.
Используешь
pg_cron или фоновые воркеры в проде?👉 @SQLPortal