# 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** | Beta - used in production | Production-ready |

<small>*¹ 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.*</small>

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. Flows 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.

```typescript
// 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.

```typescript
// 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