Ответ Microsoft на Temporal — расширение Postgres, гоняющее воркфлоу прямо в SQL

2026-й — год очереди на Postgres

Microsoft выложила в open source pg_durable — расширение для PostgreSQL для устойчивого выполнения (durable execution): отказоустойчивых долгоиграющих воркфлоу, которые переживают падения, перезапуски и фейловеры, не начиная всё с нуля. Проект набрал 361 голос и 83 комментария, а тред читается как референдум по десятилетнему спору: сколько бизнес-логики уместно держать внутри базы данных.

Что он на самом деле делает

Питч дословно из документации: долгоиграющие SQL-функции «для команд, которые и так держат своё состояние в Postgres и хотят перестать сшивать cron-задачи, воркеров, очереди и таблицы статусов, чтобы фоновая работа была надёжной». Воркфлоу описывается на SQL композируемыми операторами (~> — связать шаги, |=> — привязать именованный результат), запускается через df.start(), а Postgres делает чекпойнт состояния между каждым шагом — так что прерванный воркфлоу продолжает с последнего чекпойнта, а не с начала.

Под капотом это расширение на Rust, собранное на pgrx, поверх двух библиотек: duroxide (движок оркестрации устойчивых задач) и duroxide-pg (провайдер состояния для Postgres). Ни Redis, ни внешнего оркестратора, ни отдельных таблиц состояния — воркфлоу живёт там же, где данные, с теми же бэкапами, аутентификацией и схемами доступа, что и у базы. Репозиторий необычно откровенен о собственных границах: не используйте это, когда задача — один INSERT ... SELECT; когда нужны синхронные запросы за доли миллисекунды; когда воркфлоу охватывает разнородные системы; или когда нужна произвольная прикладная логика, которая плохо ложится на SQL.

Возражение про хранимые процедуры, переформулированное для 2026-го

Громче всего звучит мысль, что это старый антипаттерн в новой обёртке.

«Пахнет хранимыми процедурами. Их нельзя юнит-тестировать. Нельзя версионировать. Бизнес-логика в базе (проблема скрытого мозга), сложнее изолировать шумные нагрузки, никакой наблюдаемости… Хотя для чисто локальных задач внутри базы — годится. Нишевые случаи». — разработчик, перечисляющий классические возражения

«Зачем мне хранить поток управления в базе, а не в коде? Это ощущается странно». — инженер, привыкший к DAG-планировщикам вроде Airflow

Позиция бывшего прикладного инженера — от человека, который делает инструменты для шардирования Postgres, — самая взвешенная: он открыт к идее, но инстинктивно хочет держать очередь в Git.

«Хотя как бывший прикладной инженер я всё же предпочитаю держать логику очередей в коде, в Git, — но, может, с правильным тулингом меня и переубедят». — основатель проекта по шардированию Postgres

Зачем грузить долгими задачами самое плохо масштабируемое звено?

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

«Разве база — не одна из самых трудно масштабируемых частей инфраструктуры? Зачем грузить её ещё и долгими задачами?» — создатель autojump, работающий в медицинской визуализации

«Похоже, это ещё один эффект внутренней платформы, который был бы не нужен, если бы популярные языки и виртуальные машины уже поддерживали детерминизм… приостановку состояния рантайма, его (де)сериализацию и возобновление». — комментатор, ссылающийся на эффект внутренней платформы

И повторяющийся вопрос «почему не Temporal» прозвучал прямо — несколько читателей проштудировали README и всё равно не смогли понять, где pg_durable обыгрывает внешний оркестратор для воркфлоу, которые ходят во множество систем; один спросил про сравнение в лоб.

Случай, который он тихо выигрывает

Отбросьте скепсис — и останется реальная ниша, которую очерчивает сам README: если ваше состояние уже целиком живёт в Postgres, внешний сервис устойчивого выполнения означает вторую систему, которую надо держать, бэкапить, защищать и сверять с базой. pg_durable схлопывает это в один движок с одним набором гарантий. Честное прочтение треда: это не убийца Temporal — это способ удалить обвязку из воркера, очереди и таблицы статусов для большого класса задач, которым изначально незачем было покидать базу. А доверять ли Postgres ещё и роль оркестратора — ровно та ставка, которую вам предлагают сделать.