pg_durable

Long-running, fault-tolerant SQL functions for teams that already keep their state in Postgres and want to stop stitching together cron jobs, workers, queues, and status tables to make background work reliable. Define the workflow in SQL, let pg_durable checkpoint each step, and resume after crashes, restarts, or failed steps.

Durable execution is now a standard industry pattern, and pg_durable brings it inside Postgres with no extra service infrastructure required. Part of our mission to bring compute close to data.

Try pg_durable now in Azure HorizonDB, Microsoft's new PostgreSQL cloud service engineered for performance and built with pg_durable inside

Is this for me?

Who it's for

• Backend and data engineers who want workflows to live next to the data they touch.
• DBAs and SREs automating runbooks that must survive restarts and be auditable in SQL.
• Teams building data or AI pipelines that need durable execution per row, document, or batch.

The core idea

A pg_durable function is a graph of SQL steps that PostgreSQL executes and checkpoints as it goes. If the database crashes, restarts, or a step fails, execution resumes from the last durable checkpoint instead of making you reconstruct state by hand.

Workloads this is useful for

• Vector embedding pipelines: chunk, call an embedding API, and upsert into pgvector.
• Ingest pipelines: stage, deduplicate, transform, and publish large batches.
• Scheduled maintenance: detect bloat, notify, wait for approval, then run the next action.
• Fan-out aggregation: run independent queries in parallel, then join the results.
• External API workflows: enrichment, classification, and webhook-style calls from SQL.

What you're probably doing today instead

• pg_cron plus a jobs table, status columns, retry counters, and a polling worker.
• An external orchestrator such as Airflow, Temporal, Step Functions, or Argo calling back into Postgres.
• A queue plus workers plus a separate state table to coordinate retries and partial completion.
• A plpgsql procedure that works until a crash or long-running transaction forces you to start over.

Pain points it addresses

• A restart in the middle of a long job means rerunning work that already succeeded.
• One failed row or one failed API call turns into manual cleanup and uncertain replay.
• Long transactions hold locks, grow WAL, and make batch jobs fragile at larger scale.
• Parallel work in the app tier creates more places for partial-failure bugs and drift.
• The workflow logic ends up spread across SQL, workers, queues, dashboards, and status tables.

What changes in your architecture

• The workflow definition moves into SQL and starts with df.start(...).
• Retry state, progress tracking, and checkpointing move into Postgres instead of bespoke app code.
• Some app-tier workers, queue consumers, or scheduler glue can disappear entirely.
• Operational visibility comes from Postgres tables such as df.instances, using the same auth and backup model as your data.

When not to use it

• The job is already a single INSERT ... SELECT or one ordinary SQL statement.
• You need sub-millisecond synchronous request handling rather than durable background execution.
• You cannot install extensions or run a background worker in your Postgres environment.
• The workflow mostly lives outside Postgres and spans many heterogeneous systems.
• You need arbitrary application logic that does not map cleanly to SQL steps, branching, loops, or HTTP calls.

How it works

1. Define a workflow in SQL using composable operators such as ~> and |=>.
2. Start it with df.start() and get back an instance ID.
3. Let the runtime execute each step durably with checkpointing between steps.
4. Query status and results from PostgreSQL while the workflow runs or after it completes.

Limitations

The model is intentionally SQL-shaped. If a step needs arbitrary code, a non-HTTP SDK, or rich in-memory control flow, you may need to wrap that logic in a SQL function, expose it behind an HTTP endpoint for df.http(), or use a general-purpose orchestrator for that part of the system.

Features

• Durable — Function state persists to PostgreSQL. Survives crashes, restarts, and failovers.
• SQL-native — Define functions in SQL using composable operators.
• Database-aware — First-class primitives for scheduling, conditions, and parallel execution.
• Zero infrastructure — Runs as a PostgreSQL extension. No Redis, no Temporal, no external services.

Quick Example

-- A durable function that processes data in steps
SELECT df.start(
    'SELECT id FROM documents WHERE processed = false LIMIT 100' |=> 'batch'
    ~> 'UPDATE documents SET processed = true WHERE id IN (SELECT id FROM $batch.*)'
);

Packages

Tagged releases publish Debian packages for PostgreSQL 17 and 18 on amd64 from the GitHub release assets. Packages are named pg-durable-postgresql-<PG major>_<pg_durable version>-1_<arch>.deb and install the extension library, control file, and SQL upgrade files into the matching PostgreSQL installation directories.

Tagged releases also publish a ready-to-run Docker image (linux/amd64) for PostgreSQL 17 and 18 to GitHub Container Registry: ghcr.io/microsoft/pg_durable. The image installs the released Debian package on top of the official postgres image. Each release publishes immutable X.Y.Z-pg<major> and vX.Y.Z-pg<major> tags (for example 0.2.2-pg17, 0.2.2-pg18); the highest stable release additionally updates the floating pg<major> tags, and the default major (pg17) also updates latest. The PG major version is part of every tag so multiple PostgreSQL versions can be published alongside each other. Browse all published images and tags at https://github.com/microsoft/pg_durable/pkgs/container/pg_durable.

Warning: The published Docker image is intended for evaluating and learning pg_durable only — do not use it in production. It enables superuser durable instances for a frictionless out-of-the-box demo. Its HTTP egress policy uses the released Debian package's http-allow-azure-domains tier, defaulting to Azure service subdomains and api.github.com. See HTTP allowed domains for configuration in v0.2.9+. Multi-arch (linux/arm64) images are not published yet; they will follow once arm64 Debian packages are available.

Run the published image — PostgreSQL 17 and 18 can run side by side on different host ports:

# PostgreSQL 17 (the `latest` tag also points at the newest PG17 release)
docker run -d --name pg_durable_pg17 \
  -p 5432:5432 \
  -e POSTGRES_PASSWORD=secret \
  ghcr.io/microsoft/pg_durable:pg17

# PostgreSQL 18 (run alongside PG17 on a different host port)
docker run -d --name pg_durable_pg18 \
  -p 5433:5432 \
  -e POSTGRES_PASSWORD=secret \
  ghcr.io/microsoft/pg_durable:pg18

# Connect with psql (PG17 on 5432, PG18 on 5433)
psql "postgresql://postgres:secret@localhost:5432/postgres"
psql "postgresql://postgres:secret@localhost:5433/postgres"

The extension is preloaded and created in the postgres database on first init. POSTGRES_DB is ignored — pg_durable always installs into postgres so the extension and the background worker never target different databases. For reproducible deployments, pin an immutable X.Y.Z-pg<major> tag (for example 0.2.2-pg17) rather than the floating pg<major>/latest tags; immutable tags are never overwritten once published.

After installing a package, add pg_durable to shared_preload_libraries, restart PostgreSQL, and create the extension in the configured pg_durable database:

CREATE EXTENSION pg_durable;

The default pg_durable database is postgres; see User Guide for background worker configuration and privilege setup.

Each release also publishes source archives and a SHA256SUMS file. To build and install from a source archive, initialize cargo-pgrx for the target PostgreSQL installation, build the package as your normal user, then install the generated artifacts with elevated privileges:

export PG_CONFIG=/usr/lib/postgresql/17/bin/pg_config
cargo pgrx init --pg17 "$PG_CONFIG"
make PG_CONFIG="$PG_CONFIG"
sudo make install PG_CONFIG="$PG_CONFIG"

Source installation is supported on Linux and macOS for PostgreSQL 17 and 18. Windows source installation is not currently supported. Set EXTRA_FEATURES on the build command to enable an HTTP policy feature. DESTDIR may be set on make install when staging files for a package.

sudo make uninstall PG_CONFIG="$PG_CONFIG" removes the installed files again. It needs no build, so it also works from an unbuilt source tree.

Installing from PGXN

The extension is listed on PGXN, the PostgreSQL Extension Network. PGXN carries the source distribution, not a binary: pgxn install downloads the source and compiles it on your machine, so it needs the same toolchain as a source-archive build and takes several minutes. For prebuilt binaries use the Debian packages or the Docker image above.

Prerequisites:

• PostgreSQL 17 or 18, including development headers and pg_config (postgresql-server-dev-17 on Debian/Ubuntu)

• A Rust toolchain — see rustup

• pgxnclient (pip install pgxnclient)

• cargo-pgrx, matching the pgrx version pinned in Cargo.toml:

  cargo install --locked cargo-pgrx --version 0.16.1
  

Then, for a PostgreSQL installed from a package:

pgxn install --sudo -- pg_durable

Both parts of --sudo -- are load-bearing. pgxn install elevates only when told to, so without --sudo it stops before building:

ERROR: PostgreSQL library directory (...) not writable: you should run the
program as superuser, or specify a 'sudo' program

The build itself still runs as your user; only the install step is elevated. The -- separator is required because --sudo takes an optional program name and would otherwise swallow pg_durable as that argument, leaving no distribution to install. If pg_config --libdir is writable by your user — a PostgreSQL you built yourself, for instance — plain pgxn install pg_durable works.

make package registers your PostgreSQL with cargo-pgrx automatically the first time, so no separate cargo pgrx init step is needed. From a source checkout you can also run make install-pgrx to install the pinned cargo-pgrx, or make pgrx-init PG_CONFIG="$PG_CONFIG" to register PostgreSQL explicitly; set PGRX_AUTO_INIT=0 to make the build report the command to run instead of initializing on its own.

Afterwards, add pg_durable to shared_preload_libraries, restart PostgreSQL, and run CREATE EXTENSION pg_durable as described above.

pgxn uninstall --sudo -- pg_durable removes the installed files again.

Development Installation

Prerequisites

• PostgreSQL 17 or 18
• Rust (stable)
• cargo-pgrx 0.16.1

GitHub Codespace

The main branch prebuild installs PostgreSQL 17, builds pg_durable, and prepares a local cluster under ~/.pgrx with the extension ready. PostgreSQL is not left running, so start it when you begin working.

# Start PostgreSQL
./scripts/pg-start.sh

# Connect
~/.pgrx/17.*/pgrx-install/bin/psql -h localhost -p 28817 -d postgres

On a branch without a ready prebuild, run pg-start.sh — it will build and install the extension on first run (expect a few minutes):

./scripts/pg-start.sh

Other environments

Local and Dev Container

A VS Code Dev Container (.devcontainer/) provides Rust, cargo-pgrx, and PostgreSQL 17 pre-installed. For a bare local machine, install the toolchain first by following the steps in `.de