Temporal 要拉一臺 Cassandra、Celery 還在用 Redis：Hatchet 用一支 Postgres 把背景任務這層收齊

背景任務這層，過去十年的答案幾乎是按語言切的：Python 用 Celery、Ruby on Rails 用 Sidekiq、Node 用 BullMQ。每一套都綁死一個 broker——Redis 或 RabbitMQ——而且 retry 邏輯、可觀測性、排程、failure handling 都得各自重新拼湊一遍。換語言就等於換掉整套基礎建設，沒有人覺得理所當然。

Temporal 在 2019 年之後把 durable execution 這個概念帶出來，工程上是正解：把工作流的每一步寫進事件日誌，重啟、機器壞掉、程式異常都能從中斷點接回去。問題是 Temporal Server 要 Cassandra 或 PostgreSQL、要 Elasticsearch 做搜尋、要分開的 Worker 跟 Frontend 服務，光是 docker-compose 就十幾個容器，跑起來閒置記憶體輕鬆破 4GB。對沒有專職 SRE 的中小團隊，這個門檻把 durable execution 鎖在「等公司長大再說」的位置。

Hatchet 走的是另一條路。2024 年初由 Y Combinator W24 一批的兩位創辦人開源，MIT 授權，2026 年 4 月發到 v1，6 月最新版本是 0.89。整套服務只要一支 Postgres——任務狀態、事件日誌、可觀測性資料全收在裡面——SDK 涵蓋 Python、TypeScript、Go、Ruby 四種主流語言，把 Temporal 的工程價值與 Celery 等級的部署複雜度疊在一起。

Celery 跟 Sidekiq 在 2026 年的尷尬位置

Celery 寫出來的時候，Python 還沒有 type hint、async/await 也還沒進語言。整套設計圍繞著「一個任務就是一支函式、丟給 broker、worker 撿來跑」這個模型展開，要做 retry、chord、chain 都得疊上額外的概念，最後寫出來的程式碼充滿 @app.task(bind=True, max_retries=3, default_retry_delay=60) 這種裝飾器，但實際的可觀測性還是要靠另外接 Flower 或 Sentry。

Sidekiq 在 Ruby 這邊命運差不多。它本身穩定、效能也夠，但要做工作流——例如「等使用者 A 確認之後再執行下一步」——傳統的解法是塞 state machine 進資料庫，配合 sidekiq-scheduler 跟一堆 wrapper job 拼出來。可以動，但維護的人換過幾輪之後沒人講得清楚整個流程在哪裡銜接。

BullMQ 與 Bee-Queue 在 Node 生態裡的處境也類似。Redis Streams 拉起來不難，但 Redis 不是設計來當作可重播的事件日誌的——Redis 沒掛只是運氣好，掉了一個訊息要救回來幾乎沒辦法。

這些工具不會在明天突然不能用，但團隊規模拉到「需要跨語言、需要 audit 整段執行歷史、需要把 AI Agent 工作流接進來」的時候，它們的設計極限會一個一個浮上來。

Postgres 當作隊列以前被當笑話，現在是合理選擇

Hatchet 把 Postgres 當作整個系統的儲存層。任務佇列、狀態機、事件日誌、metrics、log——全部都是 Postgres 的 table。對熟悉這層歷史的工程師，這聽起來像在踩雷：Postgres 不是設計來當訊息隊列的，SELECT FOR UPDATE SKIP LOCKED 加輪詢的做法在每秒幾百個任務就會把 connection pool 吃光。

但 2026 年的 Postgres 已經不是 2014 年的 Postgres。LISTEN/NOTIFY 把輪詢需求壓低；邏輯複製把跨節點同步變便宜；JSONB 的 GIN 索引讓事件 payload 的查詢效率接近專門設計的文件資料庫；連 pgvector 都已經是 first-class extension。一臺合理配置的 Postgres 跑到每秒幾千個任務不是難事，Hatchet 官方公開的 benchmark 數字是單節點處理 1000 task/s 的 sustained throughput，p99 latency 落在 100ms 上下。

更重要的是運維成本。團隊本來就有一臺 Postgres——應用程式的主資料庫、報表系統、後台管理——多接一個 schema 給背景任務用，備份、監控、權限管理全部沿用既有那一套，不用再養一臺 Redis、不用再學 RabbitMQ 的 cluster 管理、不用煩惱 broker 跟主資料庫之間的事務一致性。對小團隊，這個「少一樣東西要顧」的價值，比抽象意義上的效能優勢更實際。

Durable Execution 把工作流變成可重播事件

Hatchet v1 的核心是 durable execution，這個概念來自 Temporal。一段工作流不是一連串會被遺忘的函式呼叫，而是一條從頭到尾可以重播的事件序列。每次呼叫外部 API、每次等待外部事件、每次 sleep——都會以事件的形式寫進 Postgres。程式中途崩潰、worker 重啟、整臺機器掛掉，重新啟動之後從中斷的事件接回去繼續跑，使用者甚至不會察覺。

具體寫起來大概像這樣：

@hatchet.workflow(on_events=["order:created"])
class ProcessOrder:
    @hatchet.step()
    async def charge(self, ctx):
        result = await stripe.charge(ctx.workflow_input["amount"])
        return {"charge_id": result.id}

    @hatchet.step(parents=["charge"])
    async def notify(self, ctx):
        await send_email(ctx.step_output("charge"))

    @hatchet.step(parents=["charge"])
    async def fulfill(self, ctx):
        await ctx.sleep_for(timedelta(minutes=30))
        await warehouse.dispatch(ctx.workflow_input["order_id"])

這段程式裡的 ctx.sleep_for(30 分鐘) 不是 Python 的 asyncio.sleep——後者在 worker 重啟時會直接消失。Hatchet 的 sleep 是把「在這個時間點之後喚醒這個工作流」寫進事件表，worker 不需要保持等待，三十分鐘到了由排程器從 Postgres 撿出來繼續執行。這個機制對「等使用者驗證信件」「等第三方審核完成」「等 AI Agent 回應」這類長時間等待的場景特別重要。

Conditional triggering 是 v1 新加的能力。工作流可以宣告「當事件 A 發生、且事件 B 在某個時段內也發生時才執行」，過去要靠應用層的狀態機自己追蹤，現在被收進引擎內。對 AI Agent 場景——例如「使用者送出問題、向量資料庫查到候選文件、需要再呼叫 LLM 驗證才能回覆」——這套原語剛好對上需求。

四個 SDK 把跨語言這件事認真做起來

Hatchet 一開始就鎖定「不要綁死一個語言」這個設計目標。Python、TypeScript、Go、Ruby 四個 SDK 共用同一份 protobuf 定義跟 gRPC 介面，wire format 由引擎本身保證，SDK 只是薄薄一層型別化的 client。後端用 Go 寫 API、前端用 TypeScript 跑 webhook handler、Python 跑機器學習 pipeline——同一個工作流可以由不同語言的 step 組成，Hatchet 引擎當作 coordinator。

對 polyglot 團隊，這個能力不只是寫程式時方便。維運的時候，不需要為了每種語言再養一套監控、一套 retry 邏輯、一套 alerting 規則。任何 SDK 送出的任務都會走同一個事件日誌、同一個 UI dashboard，工程主管打開介面就能看到所有語言的執行狀況。

AI Agent 場景在 v1 之後變成 Hatchet 文件裡頻繁出現的關鍵字。原因不複雜：Agent 工作流的形狀——多步呼叫外部 API、需要重試、需要中途等待、需要 audit——本來就跟 durable execution 完美對應。LangChain 跟 LlamaIndex 把 prompt orchestration 解決了，但「這個 agent 跑了三步之後因為 OpenAI rate limit 失敗，明天早上要從第三步接回去重試」這種需求，框架本身不解決，要靠下層的 task queue。Hatchet 把這個位置填滿了。

自架在 VPS 上的實務取捨

Hatchet 自架最直接的方法是官方提供的 docker-compose，啟動之後有幾個容器：API server、engine（任務排程核心）、dashboard 跟一支 Postgres。對中小型部署，整套閒置佔約 800 MB 到 1.2 GB 記憶體，比 Temporal 那十幾個容器跟 4GB 起跳的需求差距明顯。

Postgres 的版本要求是 14 以上，建議 16 或 17。任務量比較大的時候，把 shared_buffers 調到記憶體的四分之一、max_connections 拉到 200、work_mem 調到 32MB 起跳是合理起點。Hatchet 引擎本身對連線數的需求不算誇張——預設 10 個 worker、每個 worker 一個連線——但前端應用程式呼叫 SDK 送任務時會額外用連線，要記得算進去。

Worker 跟引擎可以跑在同一臺，也可以拆。實務上的判斷是 worker 的 CPU/記憶體用量主要取決於任務本身做什麼，跟引擎沒有關係；最常見的部署方式是引擎跟 Postgres 跑在中央 VPS 上，worker 散到不同臺機器，按負載彈性擴縮。引擎是無狀態的，所有狀態都在 Postgres 裡，水平擴展引擎本身只是把容器數量乘上去的事。

備份策略沿用既有 Postgres 那一套就行。任務歷史本身會累積，預設保留三十天可以調，超過期限的事件會被自動清理。對需要長期保留 audit log 的場景，可以接 Hatchet 的 webhook 把完成的事件即時推到 S3 或冷儲存，主庫只保留近期的活躍資料。

對比起來，Temporal 自架到能上線的工程成本明顯高一截：要懂 Cassandra 的維運、要設 Elasticsearch 的 shard、要規劃 Frontend Worker 跟 History Worker 的角色分配。Hatchet 在這個維度幾乎沒有額外負擔，「會跑一臺 Postgres + 幾個 Docker 容器」這個技能門檻，已經是多數團隊的標配。

結論：何時該認真評估 Hatchet

如果現在用 Celery 或 Sidekiq 跑著穩定的背景任務、團隊只有單一語言、沒有跨步驟長時間等待的需求——換掉的動機不強。這些工具還會撐很久。

但只要碰到三種情境之一，Hatchet 就值得進入評估清單：跨語言的服務需要共用同一套任務基礎建設、業務邏輯裡有需要可重播的長流程（金流、訂單履約、合規流程）、或者開始把 AI Agent 工作流納入正式產品。把 Postgres 當作整套引擎的儲存層在這幾年從爭議變成共識，Hatchet 是這個轉變裡的代表性產品。

自架 Hatchet 對主機的需求並不誇張——一臺中等規格的 VPS 加一臺穩定的 Postgres 就能跑起完整環境。臺灣本地的低延遲機房、Intel Gold CPU 與 NVMe SSD 對任務排程這類 I/O 密集的負載剛好對位。NCSE Network 提供的 VPS 服務以是方電訊機房為基礎，搭配多上游 IP Transit 與 99% SLA，適合用來部署 Hatchet 引擎與 worker 節點；有任務隊列基礎建設規劃需求的團隊，歡迎到 ncse.tw 進一步了解。