Skip to content

# pgflow vs DBOS

## Features

Section titled “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

Section titled “When to Choose”

### pgflow

Section titled “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

Section titled “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

Section titled “Code Examples”

### pgflow

Section titled “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 workflownew 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

Section titled “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 workflowclass 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

Section titled “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