DynamoDB vs Firestore

DynamoDB 還是 Firestore 更適合我的應用程式？

兩者都是全受管、無伺服器的 NoSQL 資料庫，但它們解決不同的問題。Amazon DynamoDB 是 AWS 的鍵值與文件儲存，針對大規模下可預測的低延遲存取而調校。Google Cloud Firestore 是 GCP 的文件資料庫，其標誌性特色是即時快照 listener，以及具離線能力的行動與網頁 SDK。若要 AWS 原生後端就選 DynamoDB；若要即時、連線用戶端的應用程式就選 Firestore。

特性	DynamoDB	Firestore
雲端平台	Amazon Web Services（AWS）	Google Cloud / Firebase（GCP）
資料模型	item 的表（鍵值與文件）；每個 item 帶有 attribute	分組為 collection 的文件；文件含巢狀欄位與 subcollection
查詢 API	透過 AWS SDK、CLI 或 PartiQL 的 `Query`/`Scan`；存取由 primary key 與索引驅動	透過用戶端與伺服器 SDK 的文件/collection 查詢，可串接 filter 與排序
即時同步與離線	無原生用戶端同步；變更擷取透過 DynamoDB Streams，由你自己的程式碼（如 Lambda）消費	內建即時快照 listener；Apple、Android 與網頁 SDK 具離線持久化與本機快取
索引	global secondary index（GSI）與 local secondary index（LSI），明確定義	自動的單欄位索引，加上供多欄位查詢用的明確複合索引
一致性	預設最終一致讀取；強一致讀取為可選（且在 LSI 上）；GSI 讀取僅為最終一致	強一致查詢
擴充	無伺服器；隨需或佈建輸送量；global table 用於跨 Region 複寫	無伺服器，具自動擴充與多區域複寫
定價模式	讀/寫容量單位（RCU/WCU）— 佈建或隨需 — 加上儲存	依文件的讀取、寫入與刪除計費，加上儲存、網路輸出與讀取的索引項目；每日免費額度
最適合	AWS 原生、高擴充、存取模式明確的後端	GCP/Firebase 上的即時、行動優先與連線用戶端應用程式

DynamoDB 較適合的時機

當你的技術堆疊在 AWS 上，且你想要一個能在流量成長時維持快速又可預測的資料庫時，DynamoDB 很合適。它的容量模型（RCU/WCU，佈建或隨需）與個位數毫秒存取，適合高輸送量後端 — 購物車、session 儲存、事件記錄，以及任何可圍繞 primary key 加 GSI 建模、存取模式明確的工作負載。

當你需要在主要表上進行強一致讀取、需要嚴謹的 IAM 型存取控管，或需要與更廣的 AWS 生態系（Lambda、S3 匯出、streams 進入分析）整合時，它也是較好的選擇。如果你的用戶端是與你自己的 API 對話而非直接與資料庫對話，那麼 DynamoDB 缺少內建用戶端同步層並不是限制。

Firestore 較適合的時機

對於即時與行動優先的應用程式，Firestore 是較強的選項。它的快照 listener 會在資料更新時立即將變更推送給連線的用戶端，而其 Apple、Android 與網頁 SDK 會將資料快取在本機，讓應用程式在離線時仍可運作，並在裝置重新連線時重新同步。這讓它自然適合聊天、協作工具、即時儀表板與消費型行動應用程式。

當你已經在 Google Cloud 或 Firebase 上、想要強一致查詢而不必逐請求選擇加入，或偏好讓用戶端直接查詢資料庫（由 security rule 守護）而非建構一層 API 時，它也是不錯的預設。它的自動索引在小規模時省去一些前期的 schema 設計工作。

使用 DynamoDB

一旦你選了 DynamoDB，DynoTable 是一款直接操作你的表的桌面用戶端 — 瀏覽與編輯 item、執行查詢，以及建立 expression，不必手寫每一個請求。它會讀取你標準的 AWS 憑證，並在你自己的帳戶中與 DynamoDB 對話。

如果你仍在手動組裝請求，免費的 DynamoDB Expression Builder會產生 key condition、filter expression 與 update expression，並為 AWS SDK、CLI、boto3 與 PartiQL 附上正確的 attribute 名稱與值 placeholder。DynoTable 是一款閉源商業應用程式；本頁是中立的技術比較，而非效能測試。

FAQ

行動應用程式該用 DynamoDB 還是 Firestore？

對於需要即時更新或離線支援的行動應用程式，Firestore 通常是更直接的選擇：其 Apple、Android 與網頁 SDK 內建即時快照 listener 與離線持久化。DynamoDB 沒有原生的用戶端同步層 — 你得使用 DynamoDB Streams 與你自己的後端來自行建構即時行為。當用戶端呼叫你自己的 API 而非直接呼叫資料庫時，DynamoDB 較為合適。

DynamoDB 和 Firestore 哪個比較便宜？

沒有哪個絕對較便宜；它們在不同軸線上計費。DynamoDB 依讀/寫容量單位（佈建或隨需）加上儲存計費，因此成本隨輸送量而定。Firestore 依每次文件讀取、寫入與刪除，加上儲存、輸出與讀取的索引項目計費，並有每日免費額度。讀取繁重或即時 listener 繁重的工作負載可能累積 Firestore 的文件讀取費用，而穩定的高輸送量工作負載在 DynamoDB 上往往能更可預測地建模。用各供應商目前的定價頁面，針對你自己的存取模式估算。

DynamoDB 有像 Firestore 那樣的即時同步嗎？

在用戶端上並非原生。Firestore 的快照 listener 會自動將變更串流到連線的應用程式。DynamoDB 的對應構件是 DynamoDB Streams，它會擷取 item 層級的變更；你以自己的程式碼（例如一個 AWS Lambda 函式）消費該 stream，將更新往下推送。這是即時的變更擷取，但送達用戶端的部分要由你自己建構。