DynamoDB vs Google Cloud Spanner
DynamoDB と Google Cloud Spanner はどちらも分散クラスターにわたって水平にスケールしますが、その核となる賭けは正反対です。DynamoDB は、既知のアクセスパターンを中心に設計された、サーバーレスな AWS の NoSQL キーバリューおよびドキュメントストアです。Spanner は、Google の TrueTime クロックを用いて、リージョンをまたいでも完全な SQL と強い(外部整合性のある)トランザクションを維持する、グローバル分散のリレーショナルデータベースです。
Should you use DynamoDB or Spanner?
AWS 上にいて、従量課金でキーベースのアクセスに予測可能なレイテンシを提供するサーバーレスな NoSQL ストアが欲しいなら、DynamoDB を選びます。リレーショナルな SQL、結合、そしてグローバル規模での強いトランザクション整合性が必要なら、Google Cloud Spanner を選びます。これは水平にスケールしつつも、リレーショナルデータベースとして振る舞う存在です。規模におけるリレーショナルの保証か、サーバーレス NoSQL のシンプルさか — これが判断の軸になります。
DynamoDB vs Spanner の概要
| 特性 | DynamoDB | Google Cloud Spanner |
|---|---|---|
| データモデル | NoSQL のキーバリューおよびドキュメント。アイテムごとに柔軟なスキーマ、最大 400 KB | リレーショナル — テーブル、行、列、スキーマ(グラフ、キーバリュー、検索の機能も備える) |
| クエリ言語 | ネイティブ API(GetItem、Query、Scan)に加え、SQL 互換言語の PartiQL | 2 つの方言による完全な SQL — GoogleSQL と PostgreSQL 互換の方言 |
| 結合とリレーション | JOIN 演算子はない。AWS はアクセスパターンを中心とした非正規化を推奨 | 完全なリレーショナル結合、外部キー、インターリーブテーブル |
| 整合性 | デフォルトは結果整合性。リクエストごとに強い整合性のある読み取り(リージョン内) | デフォルトで外部(強い)整合性。リージョンをまたぐ場合も含め、TrueTime クロックに支えられる |
| トランザクション | リージョン内で複数アイテムにまたがる ACID トランザクション | リージョンをまたぐ場合も含め、グローバルに整合した ACID トランザクション |
| スケーリングモデル | 自動パーティショニング。サーバーレスのオンデマンドまたはプロビジョンドキャパシティ | プロビジョンドコンピュート(ノード / 処理ユニット)による水平スケーリングとオートスケーリング。ストレージは別途スケール |
| マルチリージョン | Global Tables — マルチリージョン、アクティブ-アクティブレプリケーション(リージョン間は結果整合性) | リージョンをまたいで強い整合性を保つマルチリージョン構成 |
| 料金 / 運用モデル | 従量課金(オンデマンド)またはプロビジョンドキャパシティに加えストレージ。サーバーレス、AWS のみ | プロビジョンドコンピュートキャパシティに加えストレージ(およびネットワーク)。ノード/処理ユニットベース、GCP のみ |
| 最適なワークロード | 既知のキーアクセスを持ち、一貫した低レイテンシを必要とする大規模な運用アプリ | 規模において強い整合性、SQL、結合を必要とするグローバルなリレーショナルシステム |
DynamoDB が適している場合
- AWS 上にいて、サーバーレスな NoSQL が欲しい場合。 オンデマンドキャパシティはプロビジョンするものがなく、トラフィックに合わせてスケールし、アイドル時にはゼロまでスケールします。
- アクセスパターンが既知でキーベースの場合。 DynamoDB のパーティション/ソートキーモデルは、キーを読み取りに合わせて設計すれば、一貫した 1桁ミリ秒のレイテンシをもたらします。
- リレーショナル結合やグローバルな強い整合性が不要な場合。 非正規化されたキー指向のモデルが適するなら、使わない保証にお金を払わずに済みます。
- ネイティブな AWS 統合が欲しい場合。 IAM、Lambda、ストリームとの統合です。
Spanner が適している場合
- グローバル規模でリレーショナルな SQL が必要な場合。 Spanner は水平にスケールしながら結合、スキーマ、完全な SQL を維持します。スケールアウトのためにリレーショナルなセマンティクスを手放す必要はありません。
- リージョンをまたいだ強い整合性が必要な場合。 TrueTime に支えられた外部整合性により、マルチリージョンのトランザクションはあたかも直列化されたかのように振る舞います。DynamoDB の Global Tables(リージョン間は結果整合性)はこれを提供しません。
- ワークロードがリレーショナルで、クエリが柔軟な場合。 正規化されたテーブルにわたるアドホックな結合や進化するクエリは、Spanner のモデルに適します。
- GCP 上にいて、高可用性 SLA を持つマネージドなグローバルデータベースが欲しい場合。
DynamoDB を扱う
DynamoDB が適するなら、DynoTable は macOS、Windows、Linux 向けのネイティブなデスクトップクライアントです。標準の AWS 認証情報チェーンを読み取るため、データは DynamoDB に留まり、移行するものは何もありません。Spanner の SQL に慣れたチームにとって、SQL Workbench は DynamoDB のアクセスパターンのルールの範囲内で、リレーショナル的なクエリ — 結合、GROUP BY、集計 — を DynamoDB の Query/Scan にコンパイルして表現し、AI アシスタントはあなた自身の AWS Bedrock 認証情報で動作します。
SQL for DynamoDB と PartiQL vs SQL のガイドは、SQL から何が引き継がれるかを説明し、無料の DynamoDB Expression Builder は、キー条件、フィルター、更新式を SDK、CLI、PartiQL の形式で生成します。DynoTable はクローズドソースの商用アプリです。このページはその機能を説明するものであり、どのように構築されているかを説明するものではありません。
よくある質問
Spanner は DynamoDB のような NoSQL データベースですか?
いいえ。Spanner は完全な SQL、結合、スキーマを備え、分散システムのように水平にスケールするリレーショナルデータベースです。DynamoDB は JOIN 演算子を持たない NoSQL のキーバリューおよびドキュメントストアです。Spanner を際立たせる主張は、グローバル規模でリレーショナルかつ強い整合性のあるセマンティクスを維持する点にあります。
DynamoDB は Spanner のようなグローバルな強い整合性を提供しますか?
同じ形では提供しません。DynamoDB は単一リージョン内で強い整合性のある読み取りを提供し、Global Tables はリージョン間でレプリケートしますが、その間は結果整合性です。Spanner は TrueTime を用いて、リージョンをまたぐ場合も含め、トランザクションに外部(強い)整合性を提供します。
DynamoDB は Spanner を置き換えられますか?
リレーショナルな SQL やグローバルな強い整合性が不要な場合に限られます。アクセスがキーベースで、非正規化されたモデルが適するなら、DynamoDB のほうがシンプルでサーバーレスです。結合、アドホックな SQL、あるいは強い整合性のあるリージョン間トランザクションに依存しているなら、それらは Spanner の目的そのものです。置き換えるということは、データを DynamoDB のキーを中心に作り直し、それらの保証を手放すことを意味します。
関連
- DynamoDB の整合性と、マルチリージョンの Global Tablesについて学びます。
- SQL for DynamoDB と PartiQL vs SQL で何が引き継がれるかを確認します。
- 無料の DynamoDB Expression Builderでクエリを素早く組み立てます。
- DynoTable をダウンロードして、DynamoDB テーブルを扱います。
Last verified 2026-07-12 against the official AWS DynamoDB Developer Guide and Google Cloud Spanner documentation. Google Cloud Spanner is a trademark of Google LLC; referenced here for identification only.