DynamoDB vs Firestore

自分のアプリには DynamoDB と Firestore のどちらが良いですか？

どちらもフルマネージドでサーバーレスな NoSQL データベースですが、解決する課題は異なります。Amazon DynamoDB は、大規模でも予測可能な低レイテンシのアクセスに最適化された AWS のキーバリューかつドキュメントストアです。Google Cloud Firestore は GCP のドキュメントデータベースで、その特徴はリアルタイムのスナップショットリスナーと、オフライン対応のモバイルおよびウェブ SDK です。AWS ネイティブなバックエンドには DynamoDB を、リアルタイムでクライアント接続型のアプリには Firestore を選びましょう。

特性	DynamoDB	Firestore
クラウドプラットフォーム	Amazon Web Services（AWS）	Google Cloud / Firebase（GCP）
データモデル	アイテムのテーブル（キーバリューとドキュメント）、各アイテムに属性	コレクションにグループ化されたドキュメント、ドキュメントはネストされたフィールドとサブコレクションを保持
クエリ API	AWS SDK、CLI、または PartiQL 経由の `Query`/`Scan`、アクセスはプライマリキーとインデックスで駆動	クライアントおよびサーバー SDK 経由のドキュメント/コレクションクエリ、チェーン可能なフィルターと並び替え
リアルタイム同期とオフライン	ネイティブなクライアント同期なし、変更捕捉は DynamoDB Streams 経由で自身のコード（例: Lambda）が消費	組み込みのリアルタイムスナップショットリスナー、Apple、Android、ウェブ SDK でのオフライン永続化とローカルキャッシュ
インデックス	明示的に定義するグローバルセカンダリインデックス（GSI）とローカルセカンダリインデックス（LSI）	自動の単一フィールドインデックスに加え、複数フィールドクエリ用の明示的な複合インデックス
整合性	デフォルトは結果整合性のある読み取り、強い整合性のある読み取りは任意（LSI 上でも可）、GSI 読み取りは結果整合性のみ	強い整合性のあるクエリ
スケーリング	サーバーレス、オンデマンドまたはプロビジョンドスループット、マルチリージョン複製用のグローバルテーブル	自動スケーリングとマルチリージョン複製を備えたサーバーレス
料金モデル	読み取り/書き込みキャパシティユニット（RCU/WCU、プロビジョンドまたはオンデマンド）とストレージ	ドキュメント単位の読み取り、書き込み、削除、加えてストレージ、ネットワーク送信、読み取ったインデックスエントリ、無料の日次クォータ
最適な用途	AWS ネイティブで大規模、アクセスパターンが明確なバックエンド	GCP/Firebase 上のリアルタイム、モバイルファースト、クライアント接続型アプリ

DynamoDB が適している場合

スタックが AWS 上にあり、トラフィックが増えても高速で予測可能なままのデータベースが欲しいときに DynamoDB は適しています。そのキャパシティモデル（RCU/WCU、プロビジョンドまたはオンデマンド）と 1桁ミリ秒のアクセスは、高スループットのバックエンド — ショッピングカート、セッションストア、イベントロギング、そしてプライマリキーと GSI を中心にモデル化できる、アクセスパターンが十分に理解されたあらゆるワークロード — に適しています。

また、プライマリテーブルで強い整合性のある読み取りが必要な場合、IAM ベースのきめ細かなアクセス制御が必要な場合、あるいは広範な AWS エコシステム（Lambda、S3 エクスポート、分析へのストリーム）との統合が必要な場合にも、DynamoDB がより良い選択肢です。クライアントがデータベースに直接ではなく自身の API と通信するなら、DynamoDB に組み込みのクライアント同期レイヤーがないことは制約になりません。

Firestore が適している場合

Firestore はリアルタイムかつモバイルファーストのアプリにとってより強力な選択肢です。そのスナップショットリスナーはデータが更新されるとすぐに変更を接続中のクライアントにプッシュし、Apple、Android、ウェブの SDK はデータをローカルにキャッシュするため、アプリはオフラインでも動作し続け、デバイスが再接続すると再同期します。これにより、チャット、共同編集ツール、ライブダッシュボード、コンシューマー向けモバイルアプリに自然に適合します。

すでに Google Cloud または Firebase を利用している場合、リクエストごとにオプトインせずに強い整合性のあるクエリが欲しい場合、あるいは API 層を構築する代わりにクライアントがデータベースを直接クエリする（セキュリティルールで保護しつつ）ことを好む場合にも、Firestore は良いデフォルトです。その自動インデックス作成は、小規模なうちは事前のスキーマ設計作業の一部を不要にします。

DynamoDB を扱う

DynamoDB を選んだら、DynoTableは、テーブルを直接操作するためのデスクトップクライアントです — アイテムの参照と編集、クエリの実行、そしてすべてのリクエストを手書きせずに式を構築できます。標準的な AWS 認証情報を読み取り、あなた自身のアカウント内で DynamoDB と通信します。

まだリクエストを手作業で組み立てているなら、無料の DynamoDB Expression Builder が、AWS SDK、CLI、boto3、PartiQL 向けに正しい属性名と値のプレースホルダーを備えたキー条件、フィルター式、更新式を生成します。DynoTable はクローズドソースの商用アプリです。このページはベンチマークではなく、中立的な技術比較です。

よくある質問

モバイルアプリには DynamoDB と Firestore のどちらを使うべきですか？

リアルタイム更新やオフライン対応が必要なモバイルアプリには、通常 Firestore がより直接的な選択肢です。その Apple、Android、ウェブの SDK には、リアルタイムのスナップショットリスナーとオフライン永続化が標準で含まれています。DynamoDB にはネイティブなクライアント同期レイヤーがなく、DynamoDB Streams と自身のバックエンドを使ってリアルタイムの挙動を自分で構築することになります。DynamoDB は、クライアントがデータベースに直接ではなく自身の API を呼び出す場合により適しています。

DynamoDB と Firestore のどちらが安いですか？

どちらも一律に安いわけではなく、異なる軸で課金されます。DynamoDB は読み取り/書き込みキャパシティユニット（プロビジョンドまたはオンデマンド）とストレージに対して課金するため、コストはスループットに連動します。Firestore はドキュメント単位の読み取り、書き込み、削除に加えて、ストレージ、送信、読み取ったインデックスエントリに対して課金し、無料の日次クォータがあります。読み取りの多いワークロードやリアルタイムリスナーの多いワークロードは Firestore のドキュメント読み取り課金が積み上がり得る一方、安定した高スループットのワークロードは DynamoDB でより予測可能にモデル化できることが多いです。各プロバイダーの現在の料金ページを使って、自身のアクセスパターンに照らして見積もりましょう。

DynamoDB には Firestore のようなリアルタイム同期はありますか？

クライアント側にはネイティブにはありません。Firestore のスナップショットリスナーは変更を接続中のアプリに自動でストリーミングします。DynamoDB の同等の構成要素は DynamoDB Streams で、アイテムレベルの変更を捕捉します。そのストリームを自身のコード（例えば AWS Lambda 関数）で消費して更新を先へプッシュします。これはリアルタイムの変更捕捉ですが、クライアントへの配信は自分で構築します。