Microsoft открыла исходный код pg_durable PostgreSQL — расширения, которое позволяет запускать долгоживущие workflow прямо внутри базы, без отдельного оркестратора, очередей и служебных воркеров. Для команд, которые устали склеивать cron, background jobs и обработчики сообщений ради пары SQL-пайплайнов, новость выглядит не как очередной репозиторий «на посмотреть», а как заявка на пересмотр привычной архитектуры.
О проекте 10 июня 2026 года сообщает InfoQ: Microsoft выложила в open source расширение pg_durable, с помощью которого разработчики могут описывать устойчивые к сбоям процессы прямо на SQL. Идея в том, что состояние выполнения, ретраи, контрольные точки и прогресс хранятся внутри PostgreSQL, а не в приложении или внешнем control plane. В теории это означает неприятную, но честную вещь для части инфраструктуры: кое-какой «клей» на уровне приложения становится просто не нужен.
Судя по описанию, pg_durable PostgreSQL решает довольно приземлённую проблему. Когда нужно построить длинный процесс с несколькими шагами, разработчики обычно собирают его из разнородных деталей: SQL-задачи, планировщик, очередь, воркер, логика повторов после ошибок, отдельное хранение состояния. На бумаге всё это выглядит управляемо. На практике через несколько месяцев никто уже не хочет вспоминать, почему третий шаг живёт в cron, четвёртый в очереди, а восстановление после падения базы происходит по инструкции из wiki. В pg_durable workflow задаётся как граф SQL-шагов, а PostgreSQL выполняет его и фиксирует состояние по ходу работы. Если база падает, перезапускается или один из шагов завершается с ошибкой, выполнение продолжается с последней durable checkpoint, а не собирается заново вручную.
Microsoft показывает это на простом примере: сначала выбираются ID документов, которые ещё не обработаны, затем следующий шаг обновляет их статус. В синтаксисе расширения для этого используются специальные операторы. Оператор |=> связывает результат запроса с переменной, а ~> задаёт последовательный переход к следующему узлу. Запуск идёт через функцию df.start. Есть и примитивы для параллельного выполнения: два SQL-узла можно стартовать одновременно, а потом дождаться их завершения через df.join или оператор &. Иначе говоря, Microsoft пытается поднять в SQL то, что обычно живёт в Temporal-подобных системах или в самописной оркестрации на стороне приложения.
Где это может пригодиться
В качестве основных сценариев Microsoft называет пайплайны для векторных эмбеддингов, задачи обслуживания базы и workflow с внешними API. Первый кейс сейчас особенно показателен: данные нужно разбить на части, отправить во внешний embedding API, а потом записать результат обратно, например в pgvector. Обычно вокруг такого конвейера быстро нарастает служебная обвязка: очереди, retry-механика, таймеры, обработка дублей, контроль состояния после сбоя. pg_durable предлагает держать всё это ближе к данным, то есть там же, где и происходит основная работа.
Вторая группа сценариев — рутинная эксплуатация PostgreSQL. Проверка разрастания таблиц и индексов, запуск последующих действий, отправка уведомлений, ожидание ручного подтверждения и продолжение процесса после него — всё это тоже укладывается в модель «длинной функции», которая должна пережить рестарт и не потерять контекст. Для внутренних платформ и data-команд здесь есть понятный соблазн: если workflow и так в основном крутится вокруг SQL, то, возможно, его правда не нужно вытаскивать в отдельный сервис только ради дисциплины исполнения.
При этом проект специально выглядит минималистично. По данным InfoQ, архитектура состоит из самого расширения PostgreSQL и background worker, без внешнего control plane. Исполняющий слой построен на двух Rust-библиотеках: duroxide, которая даёт runtime с детерминированным replay, checkpointing, таймерами и суборкестрациями, и duroxide-pg, которая сохраняет экземпляры workflow, историю, очереди работы и прочее служебное состояние в отдельной схеме внутри PostgreSQL. Это важная деталь: Microsoft не просто добавила пару SQL-функций, а привезла в базу модель durable execution, которая уже несколько лет обсуждается как способ упростить сложные распределённые процессы.
Что это меняет для команд
На уровне тренда ход Microsoft выглядит логично. Durable execution уже закрепился как понятная инженерная идея благодаря платформам вроде Temporal и решениям, которые InfoQ раньше разбирала на примере Cloudflare. Общий посыл везде один: не заставлять разработчика вручную восстанавливать состояние после ошибок, а дать системе самой продолжить процесс с нужной точки. Разница в том, что pg_durable переносит этот подход максимально близко к данным. Не в отдельный workflow-движок, не в SaaS-оркестратор, а прямо в PostgreSQL.
Для русскоязычной IT-аудитории это важно по нескольким причинам. Во-первых, во многих компаниях PostgreSQL уже давно не просто база, а почти центр прикладной вселенной: там и транзакционная нагрузка, и аналитические задачи, и расширения вроде pgvector. Во-вторых, любая возможность убрать из стека лишний сервис сейчас рассматривается без романтики: меньше компонентов — меньше точек отказа, меньше интеграционного кода, меньше затрат на сопровождение. В-третьих, такой подход хорошо ложится на команды, где сильный SQL и слабое желание тащить полноценный оркестратор ради нескольких внутренних процессов.
Но и здесь без холодного душа не обойтись. Чем больше логики живёт в базе, тем сильнее сама база становится местом концентрации рисков. Если раньше оркестрация, очереди и служебные воркеры были вынесены наружу, теперь часть этой ответственности возвращается в PostgreSQL. Для одних это плюс: меньше сетевых прыжков, ближе данные, проще восстановление. Для других — повод спросить, не превращается ли база в ещё более тяжёлый монолит, который команда боится трогать в пятницу вечером. Особенно если workflow начинает зависеть от внешних API, таймеров и параллельных веток выполнения.
Именно поэтому судьба pg_durable, скорее всего, будет зависеть не от красоты идеи, а от того, насколько уверенно расширение поведёт себя в реальных production-сценариях: с failover, длительными задачами, обновлениями схемы и неприятными пограничными случаями. Если Microsoft удастся доказать, что durable workflow внутри PostgreSQL — это не лабораторный трюк, а рабочий способ выкинуть часть оркестрационной инфраструктуры, у разработчиков появится ещё один аргумент в пользу «меньше сервисов, больше смысла». Первоисточник: .