Skip to content

# Comparing pgflow to Other Systems

This section compares pgflow to other workflow orchestration systems, helping you understand the architectural differences, trade-offs, and when to choose each approach.

## Two Approaches to Workflows

Section titled “Two Approaches to Workflows”

Workflow systems use one of two approaches:

### Explicit Graph (pgflow)

Section titled “Explicit Graph (pgflow)”

You define the complete workflow structure upfront. The system knows all steps and their dependencies before execution starts.

    // The entire graph is defined upfrontnew Flow({ slug: 'processOrder' })  .step({ slug: 'validate' }, async (input) => { /* ... */ })  .step({ slug: 'charge', dependsOn: ['validate'] }, async (input) => { /* ... */ });

### Implicit Graph (DBOS, Inngest, Trigger.dev, Vercel Workflows)

Section titled “Implicit Graph (DBOS, Inngest, Trigger.dev, Vercel Workflows)”

The workflow structure emerges as your code executes. Steps are discovered at runtime, checkpointed, and can be replayed with memoized results.

    // The graph emerges as code runsasync function processOrder(input) {  "use workflow"; // or @DBOS.workflow() or step.run()  const validated = await validate(input);  // Step 1 discovered here  const charged = await charge(validated);   // Step 2 discovered here}

Key difference: Explicit graphs are compiled/analyzed before execution. Implicit graphs are discovered during execution and recovered through replay or checkpoints.

## Comparison Guides

Section titled “Comparison Guides”

All four systems below use the implicit graph approach - they’re similar to each other and different from pgflow’s explicit graph model.

pgflow vs DBOS Implicit graph via decorators with PostgreSQL checkpointing
pgflow vs Inngest Implicit graph via step functions with execution engine
pgflow vs Trigger.dev Implicit graph for background jobs with developer dashboard
pgflow vs Vercel Workflows Implicit graph via directives with deterministic replay

## Key Differences

Section titled “Key Differences”

When comparing pgflow to other workflow systems, these are the most important architectural differences:

🗄️ Database-Centric Orchestration

pgflow puts PostgreSQL at the center, using it not just for storage but for orchestration logic

⚡ Supabase Integration

Built specifically for the Supabase ecosystem with zero additional infrastructure

🔗 Explicit Data Dependencies

Flow steps connect through explicit data dependencies rather than procedural control flow

💾 PostgreSQL State Storage

All workflow state remains directly queryable in your Supabase database

These guides help you decide which tool is best for your specific use case based on your requirements, preferences, and existing infrastructure.