2026.06.21 アーキテクチャ PostgreSQL Cloudflare

Cloudflare Workers・コンテナ基盤・PostgreSQLサービス比較評価

Craft ERP のアーキテクチャ選定（バックエンド実行基盤 / PostgreSQL サービス）について、Cloudflare Workers 構成とコンテナ構成、および PostgreSQL サービスを比較し、現時点の採用判断と将来の再評価条件を整理した記録です。

結論：現時点は FastAPI + Docker + PostgreSQL を採用。Cloudflare Workers は将来の有力候補としてウォッチ。PostgreSQL サービスは Neon を第一候補として評価。

1. 背景

Craft ERP のアーキテクチャ検討において、バックエンド実行基盤と PostgreSQL サービスの選定を行った。本ドキュメントは、その検討で出た結論と判断理由を、継続的に更新できる評価資料として整理したものである。

本プロジェクトの最優先事項は次の2点である。

  1. 生成AI × 仕様駆動開発を実践し、継続的に開発サイクルを回せること
  2. 基本的な業務機能を実装し、実際に動作すること

Cloudflare Workers を調査した結果、その技術特性には強い魅力を感じた。一方で、本プロジェクトは「生成AI活用」「仕様駆動開発」「新規業務システム開発」という大きな挑戦をすでに含んでいる。

そのため判断基準を、「技術的に魅力的か」ではなく、「今のプロジェクトの成功確率を高めるか」に置いた。結果として、現時点では FastAPI + コンテナ構成 を採用し、Cloudflare Workers は将来の検証テーマとして整理する。

2. 評価対象

Cloudflare Workers 構成

Flutter Web
↓
Hono
↓
Cloudflare Workers
↓
Hyperdrive
↓
PostgreSQL

コンテナ構成

Flutter Web
↓
FastAPI
↓
Docker
↓
PostgreSQL

評価時点の前提

本評価は以下を前提とする。サービス仕様や料金体系の変更により、評価結果は将来的に変化する可能性がある。

前提項目内容
利用規模（現在）自社1店舗
利用規模（将来）複数顧客・最大100店舗規模も視野
初期DBサイズ約50GB
年間増加量約10GB程度
データベースPostgreSQL を採用
第一候補構成FastAPI + コンテナ
Cloudflare の用途CDN / WAF / Access での利用可能性

3. Cloudflare Workers とコンテナの比較

評価は本プロジェクトの前提に対する相対比較であり、一般論として一方が優れているという意味ではない。

比較項目Cloudflare Workers + HonoFastAPI + コンテナ本プロジェクトでの評価
開発難易度TypeScript/Hono、エッジ制約の理解が必要Python/FastAPI で素直に書けるコンテナ優位
学習コストWorkers/Queue/Workflow など新規習得が多い既存知識で着手できるコンテナ優位
AIとの相性情報量は増加中だが業務システム実例は少なめFastAPI は学習データ・実例が豊富コンテナ優位
デプロイwrangler で容易・高速イメージビルド+配布が必要Workers 優位
スケーリング自動・グローバル手動設計（VPS/ECS）が必要Workers 優位
可用性グローバル実行基盤で高い構成と運用次第Workers 優位
運用負荷低い（インフラ抽象化）中（コンテナ/ホスト管理）Workers 優位
PostgreSQL接続Hyperdrive 経由（接続プール前提）ドライバで直接接続コンテナが素直
CSV取込サイズ・実行時間制約に注意制約が少なく実装しやすいコンテナ優位
CSV出力ストリーミング設計が必要標準的に実装可能コンテナ優位
バッチ処理Cron Trigger / Queue / Workflowcron / バッチコンテナ実績はコンテナ優位
セキュリティWAF / Zero Trust / MFA が標準的自前または前段に CloudflareWorkers が手厚い
将来性非常に高い安定して高い互角（方向性が違う）
コスト小規模は割安、大規模・大容量は要試算VPS なら予測しやすい規模依存

4. Cloudflare Workers の魅力

調査の結果、特に魅力を感じた点は以下である。

  • インフラを意識しなくて良い
  • 自動スケーリング
  • グローバル実行基盤
  • WAF（Web Application Firewall）
  • Zero Trust
  • 多要素認証（MFA）
  • デプロイが容易
  • 軽量
  • 運用負荷が低い

これらは「運用に手をかけずにセキュアでスケールする基盤」を志向する場合に大きな利点となる。

5. 懸念事項

現時点での採用に対する懸念は以下である。

  • 既存の FastAPI 資産（Craft Personal などの実装知見）を直接活用できない
  • TypeScript / Hono への移行・再学習が必要
  • PostgreSQL サービスの選定が別途必要になる
  • Queue / Workflow の運用経験が不足している
  • 業務システムでのエッジ実行の運用実績を、自分たちでまだ確認できていない
  • 大きめの CSV / バッチ処理におけるエッジ実行制約（実行時間・メモリ）の検証が未了

6. 業務システムとの適合性

Craft ERP の業務システムとしての特性は以下のとおりで、いずれも PostgreSQL を中核に据えた一般的な構成である。

  • CRUD 中心の API
  • ページング前提の一覧表示
  • PostgreSQL 中心設計
  • 集計中心の分析処理
  • CSV / TSV 連携（取込・出力）
  • 外部システム連携
  • 売上分析データの出力

これらは Cloudflare Workers でも実装可能だが、「制約を意識した設計」が必要になる場面が多い。コンテナ構成のほうが、業務ロジックを素直に書き下しやすい。

7. バッチ処理の考察

業務システムでは定期バッチ（集計・取込・出力）が避けられない。

Cloudflare 案

  • Cron Trigger（定期起動）
  • Queue（非同期処理）
  • Workflow（多段・長時間処理のオーケストレーション）

コンテナ案

  • ECS Scheduled Task
  • VPS の cron
  • 専用バッチコンテナ

Cloudflare 側は機能が揃っているものの、長時間・大容量バッチでは実行制約と Queue/Workflow 設計の習熟が前提になる。コンテナ案は実績と自由度の面で扱いやすい。

8. PostgreSQL サービス比較

サービス特徴運用負荷スケーリングCloudflare 親和性バックアップ将来性
NeonPostgreSQL 特化・サーバーレス・Branching低コンピュート自動スケール高いあり（要費用確認）高い
SupabaseAuth/Realtime/Storage を含む BaaS低あり中あり高い
Aurora ServerlessAWS マネージド・自動スケール中高い中充実高い
RDS PostgreSQLAWS マネージドの定番中手動寄り中充実高い
Cloud SQLGCP マネージド中手動寄り中充実高い
コスト・運用負荷・スケーリングなどの評価は規模と利用パターンに強く依存する。本プロジェクトの前提（初期50GB・年10GB増・最大100店舗）での実コストは今後の試算項目とする。

9. Neon vs Supabase 評価

現時点の評価

現時点では Neon を第一候補 として評価する。

理由:

  • PostgreSQL 特化で構成がシンプル
  • Cloudflare との親和性が高い
  • コンピュートの自動スケール
  • Database Branching が魅力的（開発・検証で有用）
  • 今後の Cloudflare 連携も期待できる

注意事項（未評価・今後確認する項目）

  • 実運用コスト
  • バックアップ費用
  • データ転送料
  • 実運用実績
  • 50GB〜150GB 規模での費用対効果

Supabase 評価

Supabase の Auth / Realtime / Storage といった機能は魅力的である。

一方で、Craft ERP では

  • FastAPI
  • Cloudflare
  • 独自認証

を採用予定のため、Supabase の一部機能と役割が重複する可能性がある。BaaS の機能を活かしきれない構成では、Neon のようなシンプルな PostgreSQL サービスのほうが噛み合う。

10. コスト比較

Cloudflare 案で発生し得る要素

Flutter Web
Cloudflare Workers
Hyperdrive
PostgreSQL（Neon 等）
R2（ストレージ）
Queues

コンテナ案で発生し得る要素

Flutter Web
FastAPI
Docker
VPS または ECS
PostgreSQL

比較すべき項目:

  • API 実行基盤
  • PostgreSQL
  • ストレージ
  • バッチ実行
  • WAF / CDN
  • バックアップ
  • 総保有コスト（TCO）
小規模・低トラフィックでは Cloudflare 案が割安になりやすい一方、大容量データ・重い集計・大きめバッチが増えると Hyperdrive/Queues/PostgreSQL 側の費用構造が効いてくる。現状の VPS コンテナ運用は費用を予測しやすい。具体的な金額試算は、利用量が見えてきた段階での更新項目とする。

11. 今回の判断

採用する構成:

FastAPI
Docker
PostgreSQL

理由:

  • 生成AI × 仕様駆動開発を最優先する（FastAPI/Python は AI 支援の実例が豊富）
  • 基本業務機能の実現を優先する
  • 新規技術の同時導入を増やし過ぎない
  • 7月からの開発開始を優先する

Cloudflare は、当面 CDN / WAF / Access 用途での併用可能性を残しつつ、実行基盤としては将来の検証テーマに位置づける。

12. 将来の再評価条件

以下が整った場合に再評価する。

  • Cloudflare Workers の知見蓄積
  • 個人開発での運用実績
  • PostgreSQL 構成の確立
  • Queue / Workflow の検証完了
  • 実運用コストの把握

付記

  • 本資料は判断の背景・採用理由・懸念事項を含めて公開することを意図している。
  • サービス仕様・料金は変動が速いため、再評価時には各サービスの公式情報と確認日を必ず更新する。

まとめ

  • 判断基準は「技術的に魅力的か」ではなく「今のプロジェクトの成功確率を高めるか」
  • 現時点は FastAPI + Docker + PostgreSQL を採用。生成AI × 仕様駆動開発と基本業務機能の実現を優先
  • Cloudflare Workers は技術的魅力が高く、CDN/WAF/Access での併用と将来の実行基盤候補としてウォッチ
  • PostgreSQL サービスは Neon を第一候補。Supabase は機能重複の可能性があり、シンプルな Neon が噛み合う
  • 実運用コスト・バッチ制約・Queue/Workflow 検証が整った段階で再評価する

Related Service

このアーキテクチャ評価は、生成AI × 仕様駆動開発で進めている業務システム開発の検討記録です。小売現場の業務改善は、モバイル業務アプリ「クラシス」で形にしています。

クラシス（小売向け業務アプリ） Research 一覧