什麼時候不該用 DynamoDB？

當你的工作負載是分析型的，或者你的存取模式還未知時，就別用 DynamoDB。DynamoDB 是為具備已知、以鍵為基礎的存取模式的營運型（OLTP）工作負載量身打造的 — 它沒有 join、也沒有彙總函式，而臨機查詢會退回成昂貴的全資料表掃描。若是 OLAP 報表或不斷演進的關聯式需求，請挑別的引擎。

不適合的場景

臨機分析與報表（OLAP）— 這裡沒有 GROUP BY、SUM 或 AVG；每一次彙整不是一次掃描，就是一個你自己維護的預先計算彙總值。變通做法請見彙總指南。
正規化的關聯式結構 — DynamoDB 刻意省略了 JOIN 運算子；AWS 自己的建議就是去正規化。
未知或快速演進的存取模式 — 是你圍繞查詢來設計鍵。當你還說不出那些查詢時，每一個新查詢都有讓資料表重新設計或全表掃描的風險。
全文搜尋與豐富查詢 — 請見 DynamoDB 支援全文搜尋嗎？；搜尋屬於搜尋索引。
大型物件 — 項目上限是 400 KB；媒體與文件屬於 S3，資料表裡只放一個指標。

那個被拒絕、然後被標價的彙整

分析上的不合適不是品味問題。用 PartiQL 向 DynamoDB 要一個分組計數，那個語句在讀到任何東西之前就被拒絕：

SELECT status, COUNT(*) FROM "orders" GROUP BY status

ValidationException: Unsupported clause: GROUP BY
HTTP 400

拿掉分組、只要一個單純的總計，它會在更早一步、在剖析器裡就失敗：

SELECT COUNT(*) FROM "orders"

ValidationException: Unexpected path component at 1:8:5
HTTP 400

在這個方言裡 COUNT 根本不是一個函式，所以剖析器把它讀成一條屬性路徑，並在括號處放棄。

那就只剩下你自己寫的那個 Scan，而它有價碼。從頭到尾讀完一張 50 GB 的資料表要花 6,553,600 個最終一致性讀取單位，也就是掃描到的總大小換算成 4 KB 單位後再折半。在 us-east-1 隨需模式下那是 $0.82。

每小時重新整理那一個數字，一個月就是 $598。在寫入時順手維護那個計數器，或者匯出到一個分析用的儲存體，才是比較便宜的答案，而那兩件事都是 DynamoDB 不會替你做的工作。

它發光的地方

反過來的清單正是 DynamoDB 的甜蜜點：高流量的營運型工作負載，具備可預測、以鍵為基礎的讀寫，而且在任何規模下都必須維持個位數毫秒 — 購物車、工作階段、個人檔案、遊戲狀態、IoT 事件。什麼時候該用 DynamoDB 的指南講的是正面的那一半。

深入了解

如果你還在猶豫，接下來請讀何時該用 DynamoDB。已經在用 DynamoDB 而懷念 SQL 嗎？DynoTable 能從桌面對線上資料表執行 JOIN 與 GROUP BY — 而定價計算機會在你投入之前告訴你，你的工作負載會花多少錢。

參考資料

最後查證於 2026-07-13，對照上方連結的官方 AWS 文件。400 KB 這個數字已於 2026-07-28 再次確認；AWS 已把它從服務配額頁面移到 Constraints.html。

已於 2026-07-28 在 Node v24.18.0 上，透過 @aws-sdk/client-dynamodb 3.1095.0，對照 DynamoDB Local 3.3.0 重現；兩個 ValidationException 訊息皆為逐字原文。Scan 的成本是依我們同步的 AWS 定價表中 us-east-1 的費率計算的。