pgflow vs DBOS

Features

Technical Criteria	pgflow	DBOS
Architecture Model	Database-centric orchestration	Application code with durability
Transaction Handling	Any SQL client in steps	Via @DBOS.transaction() decorator
Workflow Definition	TypeScript DSL with explicit dependencies	Function annotations with regular code flow
Supabase Integration	Built-in	Limited compatibility with Supabase Edge Functions¹
Infrastructure Requirements	Zero additional (just Supabase)	Lightweight library without additional infrastructure
Type System	End-to-end type safety	Standard TypeScript typing
Failure Handling	Automatic per-step retries	Configurable step retries and workflow-level recovery
Developer Experience	DSL-based API	Decorator-based API
Maturity Level	Active development	Production-ready

¹ The DBOS documentation doesn’t explicitly mention Deno compatibility. Analysis of the dbos-transact-ts package shows it relies on Node.js-specific APIs (primarily through the pg package) that would be challenging to run in Deno/Edge Functions environments.

Both systems provide reliable database operations with proper transaction handling and exactly-once semantics - the key difference is who controls the workflow: the database (pgflow) or your code (DBOS).

When to Choose

pgflow

• Building on Supabase - Built-in integration with zero additional infrastructure, fully compatible with Edge Functions
• Working with data pipelines & ETL - Automatic parallel processing based on data dependencies
• Building graph-like workflows - Multiple steps with complex dependency relationships
• Need explicit data flow - Step dependencies are clearly visible in the workflow definition
• Want database-centric architecture - Your entire workflow logic and state lives in PostgreSQL

DBOS

• Enhancing existing applications - Add durability to your code with minimal changes
• Using standard coding patterns - Keep working with familiar TypeScript control flow
• Need production-ready solution - Benefit from a battle-tested implementation
• Working across Node.js environments - Run in diverse PostgreSQL setups (Note: limited compatibility with Deno/Edge Functions)
• Want incremental adoption - Add workflow capabilities to specific parts of your application
• Building Node.js applications - Ideal for Node.js applications with standard Node.js PostgreSQL clients

Code Examples

pgflow

pgflow puts PostgreSQL at the center of your workflow orchestration. Workflows are defined in TypeScript but compiled to SQL migrations with all orchestration logic running directly in the database. The database decides when tasks are ready to execute based on explicit dependencies.

// In pgflow, the database orchestrates the workflow
new Flow<{ url: string }>({
  slug: 'analyze_website',
})
  .step(
    { slug: 'extract' },
    async (input) => /* extract data */
  )
  .step(
    { slug: 'transform', dependsOn: ['extract'] },
    async (input) => /* transform using extract results */
  );

DBOS

DBOS puts your application code first and uses PostgreSQL as a checkpoint system. Your regular application code is enhanced with annotations/decorators, letting you use standard imperative control flow (conditionals, loops). The library checkpoints function state in PostgreSQL for recovery.

// In DBOS, your code drives the workflow
class DataPipeline {
  @DBOS.step()
  static async extract(url: string) { /* extract data */ }

  // Direct database operations using transaction decorator
  @DBOS.transaction()
  static async saveToDatabase(data: any) {
    // Uses DBOS.knexClient, DBOS.drizzleClient, etc.
    await DBOS.knexClient('data_table').insert(data);
  }

  @DBOS.workflow()
  static async analyzeWebsite(url: string) {
    const data = await DataPipeline.extract(url);
    await DataPipeline.saveToDatabase(data);
  }
}

Similarities

Both systems provide reliable database operations in workflows:

• Both can use SQL clients/ORMs and properly manage transactions
• Both track which database operations completed successfully
• Both can retry failed operations according to configured policies
• Both provide exactly-once semantics for successful transactions

The difference is architectural:

• pgflow: PostgreSQL orchestrates when steps run based on dependencies
• DBOS: Application code controls workflow sequence, with PostgreSQL tracking state