DynamoDB 支援 GraphQL 嗎？

支援，透過 AWS AppSync。AppSync 是 AWS 的受管 GraphQL 服務，而 DynamoDB 是它的原生資料來源之一：resolver 會把每一個 GraphQL 查詢或變更對應到一個 DynamoDB 操作，例如 GetItem、Query 或 PutItem。DynamoDB 本身沒有 GraphQL endpoint — GraphQL 這一層是跑在它前面的。

這對組合怎麼運作

在 AppSync 裡，你把一張 DynamoDB 資料表註冊成資料來源，然後為 GraphQL schema 的每一個欄位掛上一個 resolver。resolver 的請求處理器會把進來的 GraphQL 引數翻譯成一次 DynamoDB 呼叫，而它的回應處理器則把 DynamoDB 回傳的項目塑形回 GraphQL 回應。AWS 在列舉 DynamoDB 的無伺服器整合時把 AppSync 排在第一個，正是為了這個模式。

為什麼這是常見的技術組合

兩邊都是無伺服器的：AppSync 擴充 API 層，DynamoDB 擴充儲存與輸送量，兩邊都沒有伺服器。即時的 GraphQL subscription 也很自然地跟 DynamoDB 個位數毫秒的寫入配得上。

一個巢狀欄位要花多少

每個欄位一個 resolver，就代表每個欄位一次 DynamoDB 請求。posts { author { name } } 會解析清單一次，然後每一篇文章各解析一次 author，而那每一次都是分開計費的。

在一張擁有同一個項目集合裡的 25 篇文章與 25 個作者項目、每個約 920 位元組的資料表上，用 ReturnConsumedCapacity 量測：

Query, the 25 posts                        ConsumedCapacity 3.0
25 GetItem calls, one author each          ConsumedCapacity 12.5
1 BatchGetItem, the same 25 author keys    ConsumedCapacity 12.5

那個巢狀欄位的花費，是產生那份清單的查詢的四倍多。批次化並不會改變這件事：BatchGetItem（它本身就是一個 AppSync resolver 操作，每次呼叫上限 100 個索引鍵與 16 MB）把 25 次來回收攏成一次，但它仍然讀 25 個項目、計 25 次讀取的費。它買到的是延遲，不是容量。

以每秒十次那樣的 GraphQL 查詢來算，在 us-east-1 隨需模式下，讀取請求單位是每月 $50.92，其中光是 author 欄位就佔 $41.06 — 定價計算機可以拿你自己的數字跑同一套算式。

也因此，解法在索引鍵設計裡，而不在 resolver 裡。把巢狀欄位所回傳的東西投影進父項目或投影進一個 GSI，這樣清單查詢就已經帶著它，子 resolver 也就沒有東西要抓了。

另一條路：自備伺服器

沒有什麼規定非用 AppSync 不可 — 任何 GraphQL 伺服器（Apollo、Yoga 等等）都可以透過 AWS SDK 呼叫 DynamoDB 來解析欄位，就跟它呼叫任何其他後端一樣。取捨在於 GraphQL 這一層要你自己維運。

深入了解

GraphQL 的 resolver 一樣要遵守同一套存取模式規則 — 資料建模指南說明如何設計能服務你查詢的索引鍵，運算式建構器會產生底層的條件語法，而 DynoTable 讓你檢視你的 resolver 實際寫進去了什麼。

參考資料

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

容量數字量測於 2026-07-28，環境為 DynamoDB Local 3.3.0、Node 24.18.0 上的 @aws-sdk/client-dynamodb 3.1095.0；上方的 ConsumedCapacity 值都是引擎自己的。成本則以我們同步的 AWS 定價表中 us-east-1 隨需請求單位價格計算。