Hi,

I am building BeamTrail, a small BEAM library for durable business processes: retries, timers, signals, approval deadlines, operator controls, and crash recovery, backed by PostgreSQL.

It is not a Temporal clone and not a job queue. The goal is an embedded runtime for Erlang/Elixir/Phoenix apps that already run PostgreSQL and need long-running workflows without operating a separate workflow service.

The basic idea is:

• Active runs are supervised OTP processes.
• Business progress is stored as an append-only PostgreSQL event stream.
• State is rebuilt by reducing events.
• Snapshots and indexed projections are optimizations only.
• Leases, fencing tokens, and expected sequence checks protect concurrent writers.
• A scanner recovers unfinished runs whose lease is missing or expired.

The current use cases I am aiming at are things like:

• order fulfillment with retryable external calls;
• payment or webhook-driven sagas;
• approval flows with deadlines;
• long-running business processes that must survive VM restart;
• AI agent/tool runs where the session memory is separate, but tool calls, approvals, timers, and recovery need durable
  execution boundaries.

Current implemented pieces:

• PostgreSQL durable adapter and memory test adapter.
• Append-only event log and reducer.
• Expected-sequence append checks.
• Per-run PostgreSQL append lock.
• Lease renewal and fencing tokens.
• Supervised per-run gen_statem active runner.
• Scanner recovery with indexed recoverable-run projections.
• Retries, timeouts, and crash-atomic failure decisions.
• Cancel, park/resume, and manual requeue.
• Version mismatch gates for in-flight attempt replay and decider workflows.
• Durable signals and scanner-driven durable timers.
• Executable approval-deadline pattern.
• Crash recovery and PostgreSQL stress examples.
• EUnit, PostgreSQL integration tests, xref, Dialyzer, and secret scan in CI.

Current limits:

• No DAG, fan-out/fan-in, child workflows, or parallel command batches yet.
• No first-class human task assignment UI.
• No HTTP API or browser UI.
• No SQL-native JSON payload inspection.
• No built-in external side-effect deduplication.
• No exactly-once execution of user callbacks.

The at-least-once boundary is explicit. BeamTrail provides stable idempotency keys, but workflow code must use them when calling external systems. If a VM dies after a callback performs an external side effect but before BeamTrail records the outcome, the same attempt can be re-entered with the same idempotency key.

How I currently think about the positioning:

• If you only need background jobs, Oban is probably the better tool.
• If you need a mature multi-language workflow platform, Temporal is probably the better tool.
• BeamTrail is trying to sit in the smaller space between them: an embedded BEAM runtime for durable business processes, backed by PostgreSQL and shaped around OTP supervision.

What I would like feedback on:

1. For Phoenix/Elixir apps, does this fill a real gap between Oban jobs and Temporal?
2. Are the current APIs and semantics understandable from an Elixir user’s point of view, even though the library is written in Erlang?
3. Would durable signals, timers, approval deadlines, and crash recovery be enough to try this in a small internal workflow?
4. What would be the minimum missing feature before you would consider experimenting with it?
5. Is PostgreSQL as the durable boundary acceptable, or would you expect a different storage/runtime shape?

Useful docs:

• Design rationale
• Architecture and failure model
• Human approval deadline pattern

Repository:

There is also a GitHub Discussion for longer-form follow-up:

I am especially interested in practical feedback from people who run Phoenix/Elixir apps with background jobs, workflows, approvals, webhooks, or long-running business processes.

Thanks.