フレームワークと ORM の互換性一般的な移行パターンアーキテクチャの違いを理解する AI アシスト移行互換性に関する考慮事項移行に関してサポートが必要ですか。

PostgreSQL から Aurora DSQL への移行

Aurora DSQL は PostgreSQL と互換性があるように設計されており、ACID トランザクション、セカンダリインデックス、結合、標準 DML オペレーションなどのコアリレーショナル機能をサポートしています。既存の PostgreSQL アプリケーションのほとんどは、最小限の変更で Aurora DSQL に移行できます。

このセクションでは、フレームワークの互換性、移行パターン、アーキテクチャ上の考慮事項など、アプリケーションを Aurora DSQL に移行するための実用的なガイダンスを提供します。

フレームワークと ORM の互換性

Aurora DSQL は標準の PostgreSQL ワイヤプロトコルを使用して、PostgreSQL ドライバーおよびフレームワークとの互換性を確保します。最も一般的な ORM は、最小限の変更または変更なしで Aurora DSQL で動作します。リファレンス実装と利用可能な ORM 統合については、「Aurora DSQL アダプターとダイアレクト」を参照してください。

一般的な移行パターン

PostgreSQL から Aurora DSQL に移行する場合、一部の機能の動作が異なったり、代替構文が使用されたりすることがあります。このセクションでは、一般的な移行シナリオに関するガイダンスを提供します。

DDL オペレーションの代替方法

Aurora DSQL は、従来の PostgreSQL DDL オペレーションに代わる最新の操作を提供します。

インデックスの作成

ノンブロッキングインデックスの作成には、CREATE INDEX の代わりに CREATE INDEX ASYNC を使用します。

ベネフィット: 大規模なテーブルでのダウンタイムなしでインデックスを作成できます。

データの削除

TRUNCATE ではなく DELETE FROM table_name を使用します。

代替方法: テーブルの完全な再作成には、DROP TABLE に続いて CREATE TABLE を使用します。

システム設定

Aurora DSQL はシステムが完全に管理されているため、ALTER SYSTEM コマンドをサポートしていません。設定はワークロードパターンに基づいて自動的に処理されます。

ベネフィット: データベースのチューニングやパラメータ管理は必要ありません。

スキーマ設計パターン

Aurora DSQL との互換性のために、以下の一般的な PostgreSQL パターンを適応させます。

キーのシーケンス

自動増分シーケンスの代わりに UUID または複合キーを使用します。自動増分シーケンスは、複数のライターが同じデータを更新しようとするため、分散システムで大量の競合が発生します。UUID 同じ機能を提供しますが、調整は必要ありません。

例: id UUID PRIMARY KEY DEFAULT gen_random_uuid()

参照整合性パターン

Aurora DSQL はテーブルの関係と JOIN オペレーションをサポートしていますが、外部キーの制約はまだ適用していません。この設計の選択は、アプリケーションレイヤーの検証により柔軟性が向上し、カスケードオペレーションによるパフォーマンスのボトルネックを回避する最新の分散データベースパターンと一致しています。

パターン: 一貫した命名規則、検証ロジック、トランザクション境界を使用して、アプリケーションレイヤーに参照整合性チェックを実装します。多くの大規模なアプリケーションでは、エラー処理とパフォーマンスをより適切に制御するためにこのアプローチが好まれます。

一時的なデータ処理

一時テーブルの代わりに、CTE、サブクエリ、またはクリーンアップロジックを備えた通常のテーブルを使用します。

代替方法: セッション固有の名前を持つテーブルを作成し、アプリケーション内でクリーンアップします。

アーキテクチャの違いを理解する

Aurora DSQL の分散サーバーレスアーキテクチャは、いくつかの点で従来の PostgreSQL と意図的に異なります。これらの違いにより、Aurora DSQL の主なベネフィットであるシンプルさとスケールが実現されます。

簡素化されたデータベースモデル

クラスターごとに単一のデータベース

Aurora DSQL には、クラスターごとに postgres という名前の組み込みデータベースが 1 つ用意されています。

移行のヒント: アプリケーションで複数のデータベースを使用する場合は、論理的に分離するために個別の Aurora DSQL クラスターを作成するか、単一のクラスター内でスキーマを使用します。

一時テーブルはありません

Aurora DSQL では、一時テーブルはまだサポートされていません。複雑なクエリの代わりに、共通テーブル式 (CTE) とサブクエリを使用できます。

代替方法: 一時的な結果セットには WITH 句を使用した CTE を使用するか、セッション固有のデータ用に一意の名前を持つ通常のテーブルを使用します。

Automatic Storage Management

Aurora DSQL により、テーブルスペースと手動のストレージ管理が不要になります。ストレージは、データパターンに基づいて自動的にスケーリングおよび最適化されます。

ベネフィット: ディスク容量のモニタリング、ストレージ割り当ての計画、テーブルスペース設定の管理を行う必要がありません。

運用の簡素化

Aurora DSQL は、従来のデータベースメンテナンスタスクの多くを排除し、運用上のオーバーヘッドを削減します。

手動メンテナンスは不要

Aurora DSQL では、VACUUM、TRUNCATE、または ALTER SYSTEM コマンドは必要ありません。システムは、ストレージの最適化、統計収集、パフォーマンス調整を自動的に管理します。

ベネフィット: データベースのメンテナンスウィンドウ、バキュームスケジュール、システムパラメータの調整が不要になります。

自動パーティショニングとスケーリング

Aurora DSQL は、アクセスパターンに基づいてデータを自動的にパーティション化して分散します。手動のパーティショニングとシーケンスは必要ありません。

移行のヒント: 手動パーティショニングロジックを削除し、Aurora DSQL でデータ分散を処理できるようにします。シーケンスの代わりに UUID またはアプリケーション生成 ID を使用します。

AI アシスト移行

AI ツールを活用して、コードベースを Aurora DSQL に移行できます。

移行支援に Kiro を使用する

Kiro などのコーディングエージェントは、PostgreSQL コードを分析して Aurora DSQL に移行するのに役立ちます。

スキーマ分析: 既存のスキーマファイルをアップロードし、Kiro に潜在的な互換性の問題を特定して代替案を提案してもらいます
コード変換: アプリケーションコードを提供し、トリガーロジックのリファクタリング、シーケンスの UUID への置き換え、トランザクションパターンの変更などを Kiro に依頼します
移行計画: Kiro に特定のアプリケーションアーキテクチャに基づいたステップバイステップの移行計画の作成を依頼します

Kiro プロンプトの例:


"Analyze this PostgreSQL schema for DSQL compatibility and suggest alternatives for any unsupported features"

"Help me refactor this trigger function into application-level logic for DSQL migration"

"Create a migration checklist for moving my Django application from PostgreSQL to DSQL"

Aurora DSQL MCP サーバー

Aurora DSQL モデルコンテキストプロトコル (MCP) サーバーを使用すると、Claude などの AI アシスタントが Aurora DSQL クラスターに直接接続し、Aurora DSQL ドキュメントを検索できるようになります。これにより、AI は次のことが可能になります。

既存のスキーマを分析し、移行の変更を提案します
移行中にクエリをテストし、互換性を検証します
最新の Aurora DSQL ドキュメントに基づいて、正確で最新のガイダンスを提供します

Claude または他の AI アシスタントで Aurora DSQL MCP サーバーを使用するには、Aurora DSQL MCP サーバーのセットアップ手順を参照してください。

PostgreSQL 互換性に関する Aurora DSQL の考慮事項

Aurora DSQL には、分散アーキテクチャ、サーバーレスオペレーション、自動スケーリングを可能にするセルフマネージド PostgreSQL とは異なる機能サポートがあります。ほとんどのアプリケーションは、これらの違いを変更せずにそのまま動作します。

一般的な考慮事項については、「Amazon Aurora DSQL の使用に関する考慮事項」を参照してください。クォータと制限については、「Amazon Aurora DSQL のクラスタークォータとデータベース制限」を参照してください。

Aurora DSQL は、postgres という名前の単一の組み込みデータベースを使用します。追加のデータベースを作成することや、postgres データベースを名前変更、削除することはできません。
postgres データベースは UTF-8 文字エンコードを使用します。サーバーエンコーディングを変更することはできません。
データベースは C のみを使用します。
Aurora DSQL はシステムのタイムゾーンに UTC を使用します。Postgres は、タイムゾーンに対応したすべての日付と時刻を内部的に UTC に保存します。TimeZone 設定パラメータを設定して、クライアントへの表示方法を変換し、サーバーが内部的に UTC に変換するために使用するクライアント入力のデフォルトとして機能させることができます。
トランザクション分離レベルは PostgreSQL Repeatable Read で固定されています。
トランザクションには次の制約があります。
- トランザクションでは DDL オペレーションと DML オペレーションを混在させることはできません。
- トランザクションに含めることができる DDL ステートメントは 1 つのみです。
- トランザクションは、セカンダリインデックスの数に関係なく、3,000 行まで変更できます。
- 3,000 行の制限は、すべての DML ステートメント (INSERT、UPDATE、DELETE) に適用されます。
データベース接続は 1 時間後にタイムアウトします。
Aurora DSQL では現在、GRANT [permission] ON DATABASE を実行できません。そのステートメントを実行しようとすると、Aurora DSQL はエラーメッセージ ERROR: unsupported object type in GRANT を返します。
Aurora DSQL は、管理者以外のユーザーロールに CREATE SCHEMA コマンドの実行を許可しません。GRANT [permission] on DATABASE コマンドを実行して、データベースに対する CREATE アクセス許可を付与することはできません。管理者以外のユーザーロールがスキーマを作成しようとすると、Aurora DSQL はエラーメッセージ ERROR: permission denied for database postgres を返します。
管理者以外のユーザーは、パブリックスキーマにオブジェクトを作成できません。パブリックスキーマにオブジェクトを作成できるのは、管理者ユーザーのみです。管理者ユーザーロールには、これらのオブジェクトへの読み取り、書き込み、変更のアクセス許可を管理者以外のユーザーに付与する権限がありますが、パブリックスキーマ自体に CREATE アクセス許可を付与することはできません。管理者以外のユーザーは、オブジェクトの作成に、ユーザーが作成した別のスキーマを使用する必要があります。

移行に関してサポートが必要ですか。

移行に不可欠であるにもかかわらず、Aurora DSQL で現在サポートされていない機能に遭遇した場合、「Amazon Aurora DSQL に関するフィードバックの提供」を参照して AWS とフィードバックを共有する方法を確認してください。

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

DROP VIEW

同時実行制御