Just Use Postgres: The Case for Database-Backed Durable Workflows

Durable workflows are a powerful tool for building reliable programs. The core concept is simple: as a program runs, it regularly checkpoints its progress to a database. プログラムが実行されるにつれて、その進捗を定期的にデータベースにチェックポイントとして保存します。プログラムがクラッシュしたり失敗したりした場合、最後のチェックポイントからリロードして、最後に完了したステップから再開できます。これは本質的に、ソフトウェアエンジニアリングにおける「セーブゲーム」の仕組みです。

Traditionally, this is implemented via external orchestration. Temporal, Airflow, and AWS Step Functions のようなシステムは、中央のオーケストレーターを使用してステップを調整し、タスクをワーカーにディスパッチし、結果を別のデータストアにチェックポイントとして保存します。効果的ではありますが、このアーキテクチャは、運用上のオーバーヘッドと新たな単一障害点（SPOF）を導入します。

The Argument Against External Orchestration

External orchestration is often fundamentally overcomplicated. データベースのチェックポイントとして状態を保存することが主な目的である場合、個別のオーケストレーターサーバーを維持する論理的な理由はありません。代わりに、データベース自体がオーケストレーターとして機能できます。

In a Postgres-backed durable workflow system, application servers communicate directly with Postgres. プロセスは次のように動作します：

Submission: クライアントが Postgres workflows テーブルにエントリを作成します。
Execution: アプリケーションサーバーがテーブルをポーリングして、ワークフローをデキューして実行します。
Checkpointing: サーバーがワークフローを実行する際、各ステップの出力を直接 Postgres にチェックポイントとして保存します。
Recovery: サーバーがクラッシュした場合、別のサーバーが最後のチェックポイントからワークフローを復旧します。

By using locking clauses (like SKIP LOCKED) and database integrity constraints, servers can cooperatively dequeue workflows and detect duplicate work without a central coordinator.

The Advantages of the Postgres-Native Approach

1. Scalability and Availability

Using Postgres means that scalability and availability are no longer "orchestrator problems" but "database problems"—and Postgres is a well-studied area.

Horizontal Scaling: 容量は、より多くのワーカーサーバーを追加することで増やすことができます。
Vertical Scaling: 単一の Postgres サーバーは、1秒間に数万件のワークフローを処理できます。
Distributed Options: 極端なスケールが必要な場合、CockroachDB のような分散 Postgres バリアントや、シャード構成が利用可能です。
Availability: 高可用性は、ストリーミングレプリケーションと multi-AZ デプロイメントを活用することで実現され、数十年にわたる既存のデータベースエンジニアリングの恩恵を受けられます。

2. Built-in Observability

Because workflow states and checkpoints are stored in relational tables, observability は本質的に「無料」です。ワークフローのステータスに関するあらゆる分析クエリは、SQL で表現できます。例えば、先月エラーが発生したすべてのワークフローを見つけることは、多くのオーケストレーターで使用される独自のキーバリューストアをスキャンしたり、専用のツールを必要としたりすることなく、WHERE 句を用いた単純な SELECT 文で実現できます。

3. Reduced Security Surface Area

External orchestrators create two potential single points of failure: the orchestrator itself and its data store. 彼らも、チェックポイントを処理するために機密性の高いアプリケーションデータへのアクセスを権限限られています。オーケストレーションを Postgres に移行することで、単落障害点はデータベースのみとなり、これはほとんどのアプリケーションにとってすでに重要なインフラストラクチャです。これにより、追加の機密インフラストラクチャを強化し、監査する手間が省けます。

Critical Perspectives and Trade-offs

While the database-backed approach is compelling, developer community は、いくつかの重要な考慮事項と潜在的な落とし穴について指摘しています。

The "Build vs. Buy" Complexity

One of the most significant counter-arguments is that while a database is a great place to start, a full-featured workflow engine requires more than just state storage. コミュニティメンバーが指摘するように、高度な機能が必要になった場合、「データベースを使うだけ」という話は、ワークフローエンジンの不完全なコピーを構築することに急速に変わる可能性があります：

Once you need retries, backoff, timeouts, cancellation, versioning, visibility, task routing, rate limits, leases, heartbeats, stuck-worker detection, replay/debugging semantics, workflow migration, fanout/fanin, and long timers, audit trails, and operator tooling, the “just use a database” 「データベースを使うだけ」という話は、「ワークフローエンジンの不完全なコピーと、大量のワーカーを構築すること」になります。

Correctness and Consistency

Some critics argue that many simple implementations of database-backed workflows can be "hand-wavy" regarding correctness. クラッシュ時の強力な一貫性保証を確保することは難しく、単純な疑似コードによる実装は、本番環境でのデータ整合性の問題を引き起こす可能性があります。

Performance at Scale

While Postgres is enough, some argue that at extreme scales (TBs of data), cloud での durable Postgres の運用コストが非常に高くなる可能性があります。一部のデワパーは、コストを削減するために disk-log ベースのアーキテクチャを選択しており、他の開発者は、より小さなワークロードの場合、SQLite でさえも durable workflow のための実行可能な代替案として提案しています。

The Power of Idempotency

An alternative to complex checkpointing is the use of idempotent operations. ワークフローのすべてのステップが idempotent（べき等）であれば、システムは失敗時にジョブを最初から再起動し、完了したステップを no-ops として扱い、失敗した箇所に到達するまで進めます。これは、ワークフローの状態が大きすぎて効率的にバックアップできない場合に、より堅牢な Robust strategy となります。

Summary: Choosing Your Path

For many applications, the simplicity of simplicity of using Postgres as a durable workflow engine への恩恵は、圧倒的な利点です。データを中央集約化し、インフラストラクチャの複雑さを軽減し、SQL の力を利用して observability を実現します。しかし、複雑なオーケストレーションパターン（sophisticated fan-out/fan-in や複雑な versioning）を必要とする組織には、専用のオーケストレーターが、「NIH」 (Not Invented Here) シンドロームと長期的なメンテナンスの負担を避けるために、依然として正しい選択となる可能性があります。