什麼時候不該使用 DynamoDB？

當你的工作負載是分析型或你的存取模式未知時，請跳過 DynamoDB。DynamoDB 專為具有已知、以鍵為基礎存取模式的營運型（OLTP）工作負載而打造 — 它沒有 join 或彙總函式，而臨機查詢會退回到昂貴的全表掃描。對於 OLAP 報表或不斷演進的關聯式需求，請選擇不同的引擎。

不適合的情況

臨機分析與報表（OLAP） — 沒有 GROUP BY、SUM 或 AVG；每個彙總不是一次掃描，就是你自行維護的預先運算彙總。變通做法請見彙總指南。
正規化的關聯式 schema — DynamoDB 刻意省略 JOIN 運算子；AWS 自己的指引是反正規化。若你的模型確實需要在讀取時進行多方 join，關聯式引擎更適合 — 在 DynamoDB vs PostgreSQL 中直接比較。
未知或快速演進的存取模式 — 你圍繞查詢設計鍵。當你還無法指名查詢時，每一個新查詢都有重新設計表格或全表掃描的風險。
全文搜尋與豐富查詢 — 見DynamoDB 支援全文搜尋嗎？；搜尋屬於搜尋索引。
大型物件 — 項目上限為 400 KB；媒體與文件屬於 S3，並在表格中放一個指標。

它出色的地方

相反的清單正是 DynamoDB 的甜蜜點：高量的營運型工作負載，具備可預測、以鍵為基礎的讀取與寫入，並必須在任何規模下維持個位數毫秒 — 購物車、工作階段、設定檔、遊戲狀態、IoT 事件。何時使用 DynamoDB 指南會提出正面理由，而 DynamoDB vs. 比較會走過各項對決。

深入了解

若你舉棋不定，接著閱讀何時使用 DynamoDB。已經在用 DynamoDB 卻懷念 SQL？DynoTable 可從桌面對即時表格執行 JOIN 與 GROUP BY — 而定價計算器會在你投入之前告訴你，你的工作負載將花費多少。

參考資料

最後驗證於 2026-07-13，對照上方連結的官方 AWS 文件。

不必透過主控台就能操作 DynamoDB

DynoTable 是一款快速的 DynamoDB 桌面用戶端 — 瀏覽表格、執行 SQL 風格的查詢，並在本機編輯項目。