Upstash 完全指南

💡 免費起步：Upstash 提供免費方案，免綁信用卡 就能建立資料庫，閒置時幾乎不產生費用——很適合拿來學習、做原型或跑小型專案。實際操作見 快速開始。

目錄

• 什麼是 Upstash？
• 核心特性
• 產品線
• 快速開始（免費）
• 連線機制（重點）
• 全球複製模型
• 計費模型
• 什麼情境適合用 Upstash？
• Upstash Redis vs 傳統 Redis
• 實戰範例
• 最佳實踐
• 常見問題
• 總結

什麼是 Upstash？

Upstash 是一個 Serverless 資料平台。它把幾種常見的資料基礎設施（Redis、訊息佇列、向量資料庫）包裝成「免管理伺服器、按用量計費」的雲端服務，並且特別針對 Serverless 函數與邊緣運算（edge） 環境設計。

一句話理解

傳統 Redis / Kafka = 你要自己開機器、設定、擴容、維運
Upstash            = 你只拿到一個 endpoint，用多少付多少，閒置幾乎免費

它最大的差異化在於：除了標準的 TCP 協定，還提供 HTTP/REST 介面，所以能在「不允許開 TCP 長連線」的環境（如 Cloudflare Workers、Vercel Edge）裡使用。

核心定位

Upstash = Serverless + 按請求計費 + HTTP/REST 介面 + 全球複製

• 不是 給你一台「常駐的 Redis 伺服器」自己管
• 而是 一個「用多少算多少、閒置自動縮到趨近於零」的託管資料服務

核心特性

1. Serverless（免管理、自動縮放）

不需要佈建或管理伺服器。流量低或沒流量時，資源自動縮到極低水位；尖峰時自動承接。沒有「實例規格」要選、沒有容量要預估。

2. 按請求計費（Pay-as-you-go）

計費單位是「請求 / 命令數」，而非「機器運轉時間」。閒置時幾乎不產生費用，適合流量不固定、間歇性的工作負載。

3. HTTP/REST 介面（最大特色）

每個資料庫除了標準協定端點，還暴露一套 HTTP REST API（JSON 回應）。這讓它能在無法使用持久 TCP 連線的環境運作。

4. 邊緣 / Serverless 環境友善

官方提供 HTTP-based SDK，可在 edge function、serverless function、甚至瀏覽器中運作，不依賴傳統需要連線池的 TCP 客戶端。

5. 預設持久化與多區複製

資料跨多個可用區（AZ）複製，並有每日自動備份。設計上可作為可靠的主要資料儲存，而不只是揮發性快取。

產品線

註：Upstash 早期曾提供 Serverless Kafka 服務，後續已停止；現在的訊息 / 事件需求主要由 QStash 承接。

QStash 的特點

QStash 是一個 以 HTTP 為核心 的訊息佇列 / 任務排程器：

• 透過 HTTP 把訊息「投遞」到你指定的 URL endpoint
• 支援 最長一年 的排程（schedule / cron）
• 自動重試：endpoint 回非 2xx 時最多重試數次，最終進 死信佇列（DLQ）
• 支援 URL group 廣播（一則訊息送多個 endpoint）

因為是 HTTP-based，它天然適合 serverless：你的函數不需要常駐去「拉」訊息，而是被 QStash 用 HTTP 「推」過來。

快速開始（免費）

從免費方案起步只要幾分鐘，不需要信用卡。

步驟

1. 註冊：到 upstash.com 用 GitHub / Google 帳號登入（免費）。
2. 建立資料庫：點 Create Database → 選產品（如 Redis）→ 命名 → 選一個 主區域（挑離你的應用最近的區域，延遲最低）。
3. 取得連線資訊：在資料庫頁面複製，依執行環境二選一：
   • REST（給 edge / serverless）：UPSTASH_REDIS_REST_URL + UPSTASH_REDIS_REST_TOKEN
   • TCP（給傳統 client）：標準 redis://... 連線字串
4. 發第一個命令：把憑證設成環境變數後即可操作。

用 curl（純 HTTP，零依賴）

export UPSTASH_REDIS_REST_URL="https://xxx.upstash.io"
export UPSTASH_REDIS_REST_TOKEN="********"

# SET hello world
curl $UPSTASH_REDIS_REST_URL/set/hello/world \
  -H "Authorization: Bearer $UPSTASH_REDIS_REST_TOKEN"
# {"result":"OK"}

# GET hello
curl $UPSTASH_REDIS_REST_URL/get/hello \
  -H "Authorization: Bearer $UPSTASH_REDIS_REST_TOKEN"
# {"result":"world"}

用 JavaScript SDK

npm install @upstash/redis

import { Redis } from "@upstash/redis";

const redis = Redis.fromEnv();   // 自動讀上面兩個環境變數
await redis.set("hello", "world");
console.log(await redis.get("hello")); // "world"

免費方案有 每日命令數與資料容量上限，足以做原型與學習；流量成長後再升級到 Pay-as-you-go 或固定方案即可（見 計費模型）。

連線機制（重點）

Upstash 與傳統 Redis 差最多的就是這裡。

REST API（HTTP）vs Redis 協定（TCP）

為什麼需要 HTTP 介面？ 像 Cloudflare Workers、Vercel Edge、WebAssembly 這類執行環境 不允許開啟原始 TCP 連線，傳統 Redis client 在這裡根本連不上。Upstash 把整套 Redis 命令透過 HTTP 暴露出來，於是這些環境也能用 Redis。

Serverless 為什麼偏好 HTTP（無連線池）

傳統 Redis 用 TCP 長連線 + 連線池。但 serverless 函數是「短命、可能瞬間大量並行啟動」的——每個實例都想開一條 TCP 連線，很容易把 Redis 的連線數打爆。

HTTP REST 介面是 無狀態 的：每次操作就是一次獨立的 HTTP 請求，沒有要維護的連線、沒有連線池、沒有連線數上限的壓力。這正好契合 serverless 的執行模型。

傳統：serverless 實例 ×N ──各開 TCP 長連線──► Redis（連線數爆炸風險）
Upstash HTTP：實例 ×N ──各發無狀態 HTTP 請求──► Upstash（無連線池問題）

兩種端點同時存在：傳統伺服器環境仍可用 TCP 端點搭配標準 Redis client；邊緣 / serverless 則走 HTTP。依執行環境選擇即可。

全球複製模型

Upstash 可把資料複製到多個地理區域，運作方式是 單主多副本（primary + read replicas）：

寫入命令 ──► Primary（主）──► 成功後複製到各區 read replica
讀取命令 ──► 自動由「地理上最近」的副本回應（低延遲）

• 讀取：自動就近回應，全球使用者都能拿到低延遲
• 寫入：一律送主庫以維持一致性，再非同步複製到各副本
• 可不停機地增減區域

注意這是 最終一致性（eventual consistency） 的取捨：寫入後極短時間內，遠端副本可能還讀到舊值。

計費模型

計費單位的核心是 「請求數」，不是「運轉時間」。這跟傳統「開一台機器整月計費」的模式相反——間歇性、低頻流量 在 Upstash 上特別划算；但 持續高頻 的負載，按請求累計反而可能比固定機器貴，需要實際估算。

什麼情境適合用 Upstash？

✅ 適合的場景

❌ 不適合的場景

Upstash Redis vs 傳統 Redis

實戰範例

範例 1：HTTP SDK 操作 Redis（適用 serverless / edge）

import { Redis } from "@upstash/redis";

// 用 REST URL + token 初始化（每次操作是無狀態 HTTP 請求，免連線池）
const redis = new Redis({
  url: "https://xxx.upstash.io",
  token: "********",
});

await redis.set("user:1", JSON.stringify({ name: "Alice" }));
const user = await redis.get("user:1");

// 計數 / 限流
await redis.incr("page:views");

範例 2：純 HTTP（curl）直接打命令

# 透過 REST API 執行 SET foo bar：路徑就是命令與參數
curl https://xxx.upstash.io/set/foo/bar \
  -H "Authorization: Bearer ********"

# 執行 GET foo
curl https://xxx.upstash.io/get/foo \
  -H "Authorization: Bearer ********"
# 回應：{"result":"bar"}

範例 3：QStash 排程一個 HTTP 任務

# 請 QStash 在 60 秒後，對指定 URL 發一個 POST（帶 JSON）
curl -X POST https://qstash.upstash.io/v2/publish/https://api.example.com/job \
  -H "Authorization: Bearer ********" \
  -H "Upstash-Delay: 60s" \
  -H "Content-Type: application/json" \
  -d '{"task":"send-email","userId":123}'

# 失敗（非 2xx）會自動重試，最終進死信佇列

範例 4：限流（搭配 @upstash/ratelimit）

import { Ratelimit } from "@upstash/ratelimit";
import { Redis } from "@upstash/redis";

const ratelimit = new Ratelimit({
  redis: Redis.fromEnv(),
  limiter: Ratelimit.slidingWindow(10, "10 s"), // 每 10 秒最多 10 次
});

const { success } = await ratelimit.limit(userId);
if (!success) {
  // 回 429 Too Many Requests
}

最佳實踐

1. 依執行環境選對連線方式

• 邊緣 / serverless → 用 HTTP SDK（@upstash/redis）
• 傳統長壽命伺服器、超低延遲需求 → 可考慮 TCP 端點 + 標準 client

2. 用環境變數管理憑證

// 不要把 URL / token 寫死在程式碼
const redis = Redis.fromEnv(); // 讀 UPSTASH_REDIS_REST_URL / _TOKEN

3. 把全球複製的「最終一致性」納入設計

寫入後若立刻在另一區讀取，可能讀到舊值。對「寫後即讀且要求最新」的流程要特別留意。

4. 用 pipeline 合併多個命令減少 HTTP 往返

const p = redis.pipeline();
p.set("a", 1);
p.incr("a");
p.get("a");
const results = await p.exec(); // 一次 HTTP 請求送出多個命令

5. 估算高頻負載的成本

按請求計費對間歇流量友善，但持續高 QPS 要實際試算，必要時改用固定方案或自建。

常見問題

Q1：Upstash 跟一般 Redis 相容嗎？

A：相容 Redis API（命令層級），多數 Redis 命令可直接用。差異主要在連線方式（多了 HTTP）、託管限制與全球複製的一致性模型，而非命令語法。

Q2：為什麼在 Cloudflare Workers / Vercel Edge 要用 Upstash？

A：這些環境通常 不允許開原始 TCP 連線，傳統 Redis client 連不上。Upstash 的 HTTP REST 介面用無狀態請求運作，正好能在這些環境使用。

Q3：HTTP 介面會不會比 TCP 慢？

A：每次操作是一次 HTTP 請求，比持久 TCP 多一層協定開銷。對絕大多數應用可接受；對極端低延遲、超高頻的場景，TCP 端點或自建會更合適。可用 pipeline 合併命令降低往返次數。

Q4：資料會不會掉？只是快取嗎？

A：Upstash 預設做多區複製與每日備份，設計上可作為可靠的主資料儲存，不只是揮發性快取。但仍應依資料重要性評估備援策略。

Q5：什麼時候 Upstash 反而不划算？

A：持續高頻、大吞吐的常駐負載。按請求累計的費用可能超過「一台固定規格機器」的成本，此時固定方案或自建更經濟。

總結

核心要點

Upstash = Serverless 資料平台
          ├─ 產品：Redis / QStash / Vector / Search
          ├─ 計費：按請求，閒置近免費
          ├─ 連線：HTTP REST（邊緣友善、免連線池）+ TCP
          └─ 複製：單主多副本，全球就近讀取（最終一致）

選用決策

在邊緣 / serverless，且 TCP 不可用 / 連線池會爆？
├─ 是 → ✅ Upstash（HTTP 介面正解）
└─ 否 → 流量型態是？
        ├─ 間歇 / 不固定 → ✅ Upstash（按請求划算）
        └─ 持續高頻常駐 → 評估固定方案或自建

快速參考

記憶口訣

Upstash 三個關鍵字：

1. Serverless — 免管理、自動縮放、閒置近免費
2. HTTP — REST 介面讓邊緣 / serverless 也能用 Redis
3. 按請求 — 用多少付多少，間歇流量最划算

建立日期：2026-06-08 最後更新：2026-06-08