Node Flowdocs

Hatchet alternative: node-flow vs Hatchet

node-flow vs Hatchet — two Postgres-backed engines; node-flow defines workflows as JSON DAGs with a Conductor-compatible API, Hatchet defines them in code.

node-flow and Hatchet share a bet: Postgres is enough. Both avoid a separate broker and use PostgreSQL for durable state and queueing. They differ in where the workflow lives. Hatchet workflows — tasks, DAGs and durable tasks — are declared in code with its Python, TypeScript or Go SDKs. node-flow workflows are JSON documents the engine reads, and workers in any language poll for their steps.

node-flow vs Hatchet at a glance

node-flowHatchet
Workflow is…A JSON DAGCode (tasks, DAGs, durable tasks)
LanguagesAny, over HTTPLanguages with a Hatchet SDK
Worker connectionHTTP long-pollPersistent connection to the engine
InfrastructurePostgreSQL 18Postgres, plus the Hatchet engine
OperatorsSWITCH, FORK_JOIN, DO_WHILE, SUB_WORKFLOW, DYNAMIC, saga compensationExpressed in code
Built-in system tasksHTTP, SQL, gRPC, jq, sandboxed JS, LLM, MCP, email, webhooks — no worker neededTasks run in your workers
Human approvalsHUMAN task with inboxDurable events plus your own UI
Conductor APIYesNo
Managed offeringSelf-hostedHatchet Cloud

Choose which

Choose Hatchet for a code-first, high-throughput task queue with fan-out, concurrency keys and durable tasks inside services you control.

Choose node-flow when the definition itself should be data — reviewable, diffable, editable in a visual editor, importable from BPMN — and when non-engineers need to see and act on runs.

Frequently asked questions

Are node-flow and Hatchet both built on Postgres?

Yes. Both use PostgreSQL for durable state and queueing. node-flow’s only required dependency is PostgreSQL 18, which also holds its timers, transactional outbox and search.

Next

On this page