Update comparisons to be even more factual and well formatted (#120)

* docs: update comparison tables with new integration details and clarifications

- Changed Supabase integration from 'Native' to 'Built-in' and added configuration notes
- Clarified infrastructure requirements for DBOS and Inngest, emphasizing lightweight operation
- Updated production readiness status to 'Production-ready' for all systems
- Refined descriptions of workflow control, state storage, and event handling
- Corrected formatting inconsistencies and improved readability of comparison tables

* docs: update comparison table and usage guidance for DBOS and pgflow

- Clarify Supabase integration details and environment compatibility
- Highlight differences in workflow control and use cases
- Add notes on production readiness and environment support
- Improve clarity on when to choose each system and their features

* docs: update comparison tables for pgflow, DBOS, Inngest, and Trigger.dev

Refactor and enhance the feature comparison tables with clearer terminology, corrected
descriptions, and consistent formatting.
Added details on architecture models, infrastructure,
workflow definitions, failure handling, and maturity levels for all systems.
Improved clarity
on integration and operational aspects to better reflect current capabilities and differences.

Author: jumski

pkgs/website/src/content/docs/comparisons/dbos.mdx

@@ -7,24 +7,26 @@ sidebar:
 
 ## Features
 
-| Feature | pgflow | DBOS |
-|---------|--------|------|
-| **Core Philosophy** | 🔍 Database as orchestrator | 🔍 Application code with durability |
-| **SQL Transactions** | Any SQL client in steps | Via `@DBOS.transaction()` decorator |
+| 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** | Native | ⚠️ Possible but not optimized |
-| **Infrastructure Requirements** | Zero additional (just Supabase) | Basic recovery on single server, optional Conductor for distributed |
-| **Type Safety** | Complete end-to-end | Via standard TypeScript |
-| **Retry & Recovery** | Automatic per step | Automatic per workflow |
-| **Learning Curve** | New DSL to learn | New decorator pattern to learn |
-| **Production Readiness** | ⚠️ MVP/Early stage | Production-ready |
+| **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 |
+
+<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** - Native integration with zero additional infrastructure 
+- **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
@@ -34,8 +36,9 @@ Both systems provide reliable database operations with proper transaction handli
 - **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 environments** - Need to run in diverse PostgreSQL setups (not just Supabase)
+- **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
 
@@ -94,4 +97,4 @@ Both systems provide reliable database operations in workflows:
 
 The difference is architectural:
 - pgflow: PostgreSQL orchestrates when steps run based on dependencies
-- DBOS: Application code controls workflow sequence, with PostgreSQL tracking state
+- DBOS: Application code controls workflow sequence, with PostgreSQL tracking state

pkgs/website/src/content/docs/comparisons/inngest.mdx

@@ -7,20 +7,20 @@ sidebar:
 
 ## Features
 
-| Feature | pgflow | Inngest |
-|---------|--------|---------|
-| **Core Philosophy** | 🔍 Database as orchestrator | 🔍 Durable execution engine |
-| **Infrastructure** | Zero additional (just Supabase) | Hosted service or self-hosted |
+| Technical Criteria | pgflow | Inngest |
+|-----------------|--------|---------|
+| **Architecture Model** | Database-centric orchestration | Durable execution engine |
+| **Infrastructure Requirements** | Zero additional (just Supabase) | Hosted service or self-hosted |
 | **Workflow Definition** | TypeScript DSL with explicit dependencies | Step-based functions with checkpoints |
-| **Supabase Integration** | Native | ⚠️ Possible but not optimized |
-| **Type Safety** | Complete end-to-end | Via standard TypeScript |
-| **Retry & Recovery** | Automatic per step | Automatic per step |
-| **Execution Model** | Database-driven DAG | Linear step-by-step with state persistence |
-| **Step State** | Input/output data stored in database | Input/output memoized in execution service |
-| **Wait/Sleep** | Not directly supported (use pgcron) | Built-in sleep and waitForEvent capabilities |
-| **Production Readiness** | ⚠️ MVP/Early stage | Production-ready |
-| **Dashboard** | None (SQL queries for visibility) | Comprehensive web dashboard |
-| **Concurrency Control** | Simple per-flow limits | Advanced throttling and concurrency controls |
+| **Supabase Integration** | Built-in | Requires manual configuration |
+| **Type System** | End-to-end type safety | Standard TypeScript typing |
+| **Failure Handling** | Automatic per-step retries | Automatic per-step retries |
+| **Execution Structure** | Database-driven DAG | Linear step-by-step with state persistence |
+| **State Management** | Input/output data stored in database | Input/output memoized in execution service |
+| **Time-based Operations** | Via Supabase pg_cron | Built-in sleep and waitForEvent capabilities |
+| **Maturity Level** | Active development | Production-ready |
+| **Monitoring Tools** | SQL queries for visibility | Comprehensive web dashboard |
+| **Concurrency Management** | Simple per-flow limits | Advanced throttling and concurrency controls |
 | **Event System** | No built-in event system | Rich event-driven architecture |
 
 Both systems provide reliable task execution with proper retries and error handling. The key difference is who controls the workflow orchestration: the database (pgflow) or a durable execution engine (Inngest).
@@ -122,4 +122,4 @@ The difference is architectural:
 - **Possible integration** - Can work with Supabase but not specifically designed for it
 - **Additional infrastructure** - Requires either hosted service or self-hosted instance
 - **Event bridging** - Requires connecting Supabase events to Inngest's event system
-- **Separate state storage** - Workflow state stored outside your Supabase database
+- **Separate state storage** - Workflow state stored outside your Supabase database

pkgs/website/src/content/docs/comparisons/trigger.mdx

@@ -7,21 +7,21 @@ sidebar:
 
 ## Features
 
-| Feature | pgflow | Trigger.dev |
-|---------|--------|-------------|
-| **Core Philosophy** | 🔍 Database as orchestrator | 🔍 Background job execution and orchestration |
-| **Infrastructure** | Zero additional (just Supabase) | Hosted service with dashboard or self-hosted |
+| Technical Criteria | pgflow | Trigger.dev |
+|-----------------|--------|-------------|
+| **Architecture Model** | Database-centric orchestration | Background job execution and orchestration |
+| **Infrastructure Requirements** | Zero additional (just Supabase) | Hosted service with dashboard or self-hosted |
 | **Workflow Definition** | TypeScript DSL with explicit dependencies | TypeScript functions with tasks and subtasks |
-| **Supabase Integration** | Native | ⚠️ Possible but not native |
-| **Type Safety** | Complete end-to-end | Via standard TypeScript |
-| **Retry & Recovery** | Automatic per step | Configurable per task |
-| **Lifecycle Hooks** | No explicit hooks | Rich hooks (init, cleanup, onSuccess, onFailure) |
-| **Learning Curve** | New DSL to learn | Function-based API with lifecycle hooks |
-| **Production Readiness** | ⚠️ MVP/Early stage | Production-ready |
-| **Dashboard** | None (SQL queries for visibility) | Comprehensive web dashboard |
-| **Execution Model** | Database-driven DAG | Task/subtask hierarchy |
-| **Concurrency Control** | Simple per-flow limits | Advanced queues and limits |
-| **Scheduler** | Built into Supabase (pg_cron) | Built-in cron scheduler |
+| **Supabase Integration** | Built-in | Requires manual configuration |
+| **Type System** | End-to-end type safety | Standard TypeScript typing |
+| **Failure Handling** | Automatic per-step retries | Configurable per-task retries |
+| **Event Handling** | No explicit hooks | Rich hooks (init, cleanup, onSuccess, onFailure) |
+| **Developer Experience** | DSL-based API | Function-based API with lifecycle hooks |
+| **Maturity Level** | Active development | Production-ready |
+| **Monitoring Tools** | SQL queries for visibility | Comprehensive web dashboard |
+| **Execution Structure** | Database-driven DAG | Task/subtask hierarchy |
+| **Concurrency Management** | Simple per-flow limits | Advanced queues and limits |
+| **Scheduling Capabilities** | Built into Supabase (pg_cron) | Built-in cron scheduler |
 
 Both systems provide reliable task execution with proper retries and error handling. The key difference is who controls the workflow orchestration: the database (pgflow) or the task execution platform (Trigger.dev).