Comparison

Choosing a durable workflow engine is mostly a question of where you want the durability boundary to live. Some products give you a managed control plane. TanStack Workflow gives you a headless TypeScript engine and lets you choose the runtime, store, scheduler, and deployment target.

That is the core positioning: durable execution for TypeScript apps without requiring your application logic to move into a workflow platform. Use a managed workflow product when you want that product to own execution. Use TanStack Workflow when you want workflows to remain app-embedded, storage-adapter-driven, and portable across hosts.

This comparison shows how TanStack Workflow fits against the workflow systems teams commonly evaluate. It focuses on product shape and operational trade-offs, not every feature or pricing detail. If you use one of these systems and see something that should be corrected, please suggest a change with notes or source links.

Capability matrix

Legend: ✅ first-class fit, 🟡 possible or partial fit, 🔴 not a primary fit. The TanStack signal column explains whether the row is a differentiator, table stakes, or an area where competitors set the bar we need to meet. This matrix compares product fit, not identical APIs. When public documentation does not clearly support a first-class claim, the cell is marked partial.

Capability	TanStack signal	TanStack Workflow	Cloudflare Workflows	Temporal	Inngest	Trigger.dev	AWS Step Functions	Vercel Workflow / WDK
Headless library embedded in your app	Differentiator	✅	🔴	🔴	🔴	🔴	🔴	🟡
Bring your own durable store	Differentiator	✅	🔴	🟡	🔴	🟡	🔴	🟡
No required external service	Differentiator	✅	🔴	🔴	🔴	🟡	🔴	🔴
Runs across Cloudflare, Railway, Netlify, Node, AWS, Vercel	Differentiator	✅	🔴	🟡	✅	🟡	🔴	🟡
Plain TypeScript workflow authoring	Table stakes	✅	✅	✅	✅	✅	🟡	✅
Explicit durable steps	Table stakes	✅	✅	✅	✅	✅	✅	✅
Durable sleep / timers	Table stakes	✅	✅	✅	✅	✅	✅	✅
Wait for external events	Table stakes	✅	✅	✅	✅	✅	✅	✅
Human approval gates	Catch up to Temporal-style workflows	✅	🟡	✅	🟡	🟡	🟡	🟡
Recurring schedules / cron	Table stakes	✅	🟡	✅	✅	✅	✅	✅
Schedule pause/resume/backfill controls	Catch up to Temporal, Inngest, Trigger.dev	🟡	🔴	✅	✅	🟡	🟡	🟡
Durable queues / concurrency controls	Catch up to managed task platforms	🟡	✅	✅	✅	✅	✅	✅
Version routing for paused runs	Catch up to Temporal and Trigger.dev	✅	🟡	✅	🟡	✅	✅	🟡
Run search, replay, retry, and retention operations	Catch up to mature control planes	🟡	✅	✅	✅	✅	✅	🟡
Devtools / dashboard included	Catch up to managed platforms, TanStack-style	🟡	✅	✅	✅	✅	✅	✅
Managed control plane included	Intentional non-goal	🔴	✅	🟡	✅	✅	✅	✅

Product shape

Product / library	Form factor	Programming model	Persistence boundary	Portability	Best fit
TanStack Workflow	Headless core plus optional capability packages for stores, timers, schedules, queues, and devtools.	createWorkflow + explicit ctx.step, ctx.sleep, ctx.waitForEvent, ctx.approve.	A WorkflowStore you own or configure. Store adapters provide event logs, run state, timer indexes, schedule records, leases, search indexes, and retention.	High. Same workflow code across Cloudflare, Railway, Netlify, Node, AWS, Vercel, and custom infrastructure.	Teams that want TanStack-style primitives, app-embedded durable execution, framework portability, and control over persistence.
Cloudflare Workflows	Cloudflare-managed workflow product.	Worker workflow classes, steps, sleeps, events.	Cloudflare managed workflow state.	Low to medium. Cloudflare-oriented.	Cloudflare-native durable workflows.
Temporal	Dedicated workflow server/control plane plus workers.	Deterministic workflow code + Activities, Signals, Queries, Updates.	Temporal event history in Temporal service/database.	Medium. Portable infrastructure, but you operate or adopt Temporal.	Teams that want the deepest mature workflow control plane.
Inngest	Managed/serverless event workflow platform.	Event-triggered functions with durable step.* APIs.	Inngest managed history/state.	Medium. Framework integrations, but platform-bound.	Serverless event workflows with strong managed DX.
Trigger.dev	Managed/self-hostable background task platform.	Tasks, waits, queues, schedules.	Trigger managed/self-hosted task run state.	Medium. Self-hostable, but task-platform oriented.	Background jobs, queues, schedules, replays, and operational task UX.
AWS Step Functions	Managed state machine service.	JSON/YAML or SDK-defined state machines.	AWS managed execution history.	Low to medium. AWS-native.	Enterprise/serverless workflows inside AWS.
Vercel Workflow / WDK	Managed Vercel platform plus open SDK/world abstraction.	"use workflow" / "use step" directives and WDK APIs.	Vercel managed persistence for state/event logs on Vercel; swappable worlds in WDK.	Medium. WDK has worlds, but Vercel Workflow value is Vercel-managed.	Best native Vercel choice when you want Vercel to own the workflow platform.

Adjacent systems

These products are still useful reference points, but they are narrower, newer, or more architectural than the main comparison set.

Product / library	Why it matters	Why it is not in the main matrix
Netlify Async Workloads	Important partner deployment-native reference for Netlify and useful for side-by-side demos with TanStack Workflow on Netlify.	It is Netlify-specific and less widely evaluated as a standalone workflow platform.
DBOS	Strong reference for Postgres-backed durable execution, schedules, and queues.	It is more of a database-backed application/runtime architecture than a broad workflow-platform comparison target.
Restate	Strong reference for durable service handlers, virtual objects, workflow routing, and deployment versioning.	It is adjacent to workflows, but the main mental model is durable services rather than common app-embedded workflow primitives.

How to read this

TanStack Workflow is intentionally smaller than managed workflow platforms. The core engine handles deterministic replay, durable steps, pauses, signals, approvals, and version routing. Capability packages provide production store, timer, schedule, queue, host, and devtools integrations without making the core engine own your deployment target, database, cron system, queue, or dashboard.

That split is the point:

If you want a managed platform with an included control plane, Cloudflare Workflows, Temporal, Inngest, Trigger.dev, AWS Step Functions, or Vercel Workflow may be the right fit.
If you want a TypeScript workflow engine that can run inside your app, on your chosen host, against your chosen durable store, TanStack Workflow is the headless option.
The production surface is assembled from capability packages: durable store adapters, timer drivers, schedule records, queue/concurrency helpers, host adapters, and devtools.

The advantage is not that TanStack Workflow has a bigger control plane. The advantage is that it does not need one to be useful. It gives you durable execution as a composable app primitive, then lets your infrastructure remain your infrastructure.

Vercel Workflow note

Vercel Workflow is an important comparison for serverless TypeScript apps. It has a similar developer promise: write normal async TypeScript, split durable work into steps, sleep without consuming compute, resume from external events, and let the platform handle persistence and replay.

The difference is the product boundary.

Question	Vercel Workflow / WDK	TanStack Workflow
What do you adopt?	A managed Vercel workflow platform, powered by WDK, Vercel Functions, Vercel Queues, and Vercel-managed persistence.	A headless TypeScript engine inside your app, plus whichever store/timer/schedule adapters you choose.
How do you mark durable code?	Directive model: "use workflow" and "use step".	Explicit API model: createWorkflow, ctx.step, ctx.sleep, ctx.waitForEvent, ctx.approve.
Where does persistence live?	On Vercel, state and event logs live in Vercel-managed persistence. WDK also has swappable "worlds" such as Postgres for self-hosting.	In a RunStore you own or configure. The event log, run state, timer index, and schedule records are part of the adapter contract.
Who owns timers?	Vercel Workflow owns the timer system. Long sleeps likely combine persisted deadlines with bounded queue wakeups.	Core records the deadline. A timer driver/store adapter claims due timers and resumes runs.
Who owns operations UI?	Vercel dashboard and Workflow observability.	TanStack devtools/admin APIs are planned capability packages.
Best fit	Teams already deploying on Vercel that want the managed workflow product and do not mind the Vercel runtime boundary.	Teams that want durable workflows to stay part of their app architecture and remain portable across Cloudflare, Railway, Netlify, Node, AWS, Vercel, and custom infrastructure.

So the positioning is not "TanStack Workflow works on Vercel and Vercel Workflow doesn't." Vercel owns the Vercel-native experience.

The positioning is:

Use Vercel Workflow when you want Vercel to be the workflow platform. Use TanStack Workflow when you want durable execution as an app-embedded, explicit, storage-adapter-driven TanStack primitive.

Current recommendation

For production-style TanStack Workflow deployments, use a durable store as the system boundary. Postgres is the best first target because it can hold run state, the append-only event log, due-timer indexes, schedule records, leases, run search indexes, and retention policies in one portable substrate.

On serverless hosts like Cloudflare, Netlify, and Vercel, provider cron or scheduled functions should wake bounded timer sweeps. The database decides whether a workflow is actually due to resume.

Capability matrix#

Product shape#

Adjacent systems#

How to read this#