DynamoDB vs PostgreSQL

DynamoDB と PostgreSQL は異なる問題を解決します。DynamoDB はスケールと予測可能なレイテンシに最適化されたサーバーレスな NoSQL データベースです。PostgreSQL は柔軟なクエリとデータ整合性に最適化された成熟したリレーショナルデータベースです。このページでは、宣伝文句ではなくワークロードで選べるよう、両者を事実に基づいて比較します。

DynamoDB と PostgreSQL の違いは何ですか？

DynamoDB はフルマネージドでサーバーレスな キーバリューおよびドキュメント型 NoSQL データベースで、どんな規模でも 1桁ミリ秒のパフォーマンスを提供しますが JOIN 演算子がないため、既知のアクセスパターンに沿ってデータをモデル化します。 PostgreSQL はオープンソースの オブジェクトリレーショナル SQL データベースで、フルの結合、豊富な型システム、ACID トランザクションを備え、アドホックなリレーショナルクエリのために設計されています。アクセスパターン、規模、クエリの柔軟性で選びます。

DynamoDB と PostgreSQL の概要

特性	DynamoDB	PostgreSQL
データモデル	NoSQL — キーバリューとドキュメントの両モデルをサポート。柔軟でアイテムごとのスキーマ	オブジェクトリレーショナル — 定義され強制されるスキーマを持つテーブル・行・列
クエリ言語	専用 API（`Query`/`Scan`/`GetItem`）に加え、SELECT/INSERT/UPDATE/DELETE 向けの SQL 互換言語 PartiQL	フルの SQL。PostgreSQL 18 は SQL:2023 Core の 177 の必須機能のうち少なくとも 170 に準拠
結合と関係	JOIN 演算子はなし。AWS はデータモデルの非正規化を推奨	テーブル間のフルのリレーショナル結合、外部キー、制約
インデックス	グローバル/ローカルセカンダリインデックスにより代替キーでクエリできる	B-tree、hash、GiST、SP-GiST、GIN、BRIN に加え、部分・式・カバリングインデックス
整合性	デフォルトは結果整合性。強い整合性のある読み取りは任意選択。ネイティブな ACID トランザクション	2001 年以来 ACID 準拠。MVCC によりデフォルトで強い整合性
スケーリング	水平 — データを自動的にパーティショニング。サーバーレスのオンデマンドモードが上下（ゼロまで）にスケール	垂直スケーリングに加え、読み取りスケールアウト向けのリードレプリカ。書き込みスケールアウトにはパーティショニングや外部ツールが必要
トランザクション	1 つ以上のアイテムとテーブルにまたがるサーバーサイドの ACID トランザクション。リクエストごとの上限あり	フルの複数ステートメントトランザクション、セーブポイント（ネストしたトランザクション）、MVCC 同時実行制御
ホスティング / マネージド	サーバーレス、AWS 限定。オンデマンドまたはプロビジョンドキャパシティ課金	オープンソースでどこでも自己ホスト可能。マネージドの選択肢に Amazon RDS for PostgreSQL や Aurora PostgreSQL-Compatible Edition
最適なワークロード	既知のアクセスパターンを持つ大規模な運用アプリ（カート、セッション、リーダーボード、イベントデータ）	結合、アドホックなクエリ、強いデータ整合性を要するリレーショナルおよび分析ワークロード

DynamoDB が適している場合

アクセスパターンが既知で、優先事項がアドホックなクエリではなく規模における予測可能なレイテンシである場合は DynamoDB を選びます。

ユーザーが数百であろうと数億であろうと、一貫した 1桁ミリ秒の読み取りと書き込みが必要である。
パッチすべきサーバーも計画すべきキャパシティもなく、アイドル時にゼロまでスケールするオンデマンド課金を備えたサーバーレスなデータベースが欲しい。
ワークロードがキー指向またはアイテム指向で（ユーザープロファイル、セッション、ショッピングカート、リーダーボード、イベントストリーム）、DynamoDB のパーティション/ソートキーモデルに合致する。
独自のレプリケーションを構築せずに、マルチリージョンかつマルチアクティブなレプリケーションと高可用性の SLA が欲しい。

トレードオフ: 結合がなく、実行するクエリに合わせてキーを設計しなければなりません。後からのアクセスパターンの手直しは SQL よりも難しくなります。

PostgreSQL が適している場合

水平スケールよりもクエリの柔軟性とリレーショナルの整合性が重要な場合は PostgreSQL を選びます。

正規化されたテーブルにまたがる結合、集計、アドホックなクエリが必要で、アクセスパターンが進化し続ける。
フルの SQL、豊富な型システム（JSON/JSONB、配列、PostGIS による地理空間）、データ整合性のための強制された制約が欲しい。
データセットとトラフィックが、リードレプリカ付きの垂直スケールされたプライマリに合致する、または書き込みスケールアウトのためにパーティショニング/シャーディングのツールを追加することに抵抗がない。
自己ホストしたい、単一ベンダーのロックインを避けたい、または好みのクラウドでマネージドな Postgres を動かしたい。

トレードオフ: サーバーレスな NoSQL データベースよりも、特に非常に高い書き込みスループットにおいて、スケーリングと運用の多くを自分で担うことになります。

DynamoDB を扱う

DynamoDB を選んだら、DynoTable はそれ専用に作られたデスクトップクライアントです。アイテムの閲覧と編集のためのネイティブな GUI、 DynamoDB のアクセスパターンのルールの範囲内でリレーショナル形状のクエリ — 結合、 GROUP BY、集計 — を DynamoDB 自身の Query/Scan 操作にコンパイルして表現する SQL Workbench、そしてスキーマとデータがあなたのアカウントに留まるようあなた自身の AWS Bedrock 認証情報で動く AI アシスタントを提供します。 Postgres から移ってきて SQL を書けないのが物足りない場合は、 SQL for DynamoDB ガイドと PartiQL vs SQL ガイドが、何が引き継がれ何が引き継がれないかを説明します。

素早い単発のクエリには、無料の DynamoDB Expression Builder が予約語と属性名を正しく扱いながら、正確なキー条件、フィルタ式、更新式を生成します — インストール不要です。

よくある質問

DynamoDB は PostgreSQL を置き換えられますか？

一般的には無理です — 両者は異なるワークロードを対象としています。DynamoDB は明確に定義されたアクセスパターンを持つ大規模な運用アプリケーションにおいて、サーバーレスなスケーリングと予測可能なレイテンシが優先事項である場合には PostgreSQL を置き換えられます。結合、アドホックなリレーショナルクエリ、絶えず進化するクエリ対象に依存する場面 — PostgreSQL の強み — には不向きです。多くのチームは両方を運用します: リレーショナルおよび分析作業には PostgreSQL、高スループットなキーアクセスのパスには DynamoDB です。

DynamoDB は SQL や結合をサポートしますか？

DynamoDB はテーブルに対する SELECT、INSERT、UPDATE、DELETE 向けの SQL 互換クエリ言語 PartiQL をサポートしますが、JOIN 演算子は サポートしません — AWS は代わりにデータの非正規化を推奨します。PostgreSQL はテーブル間の結合を含むフルの SQL をサポートします。ネイティブな結合なしで関係をモデル化する方法は DynamoDB JOIN ガイドを参照してください。

DynamoDB は PostgreSQL より安いですか？

ワークロード次第なので、コストは想定するのではなくモデル化すべきものとして扱ってください。DynamoDB は読み取り/書き込みリクエストと格納データ（オンデマンドまたはプロビジョンドキャパシティ）で課金され、アイドル時にゼロまでスケールするため、急峻またはベースラインの低いトラフィックでは安くなりえます。Amazon RDS や Aurora のようなマネージドな PostgreSQL は一般に、継続的に稼働するプロビジョンドなコンピュートとストレージで課金され、安定したクエリ中心のワークロードではより費用対効果が高くなりえます。決める前に、実際のアクセスパターンに対して両方を見積もってください。