# PostgreSQL から Aurora DSQL への移行
Aurora DSQL は [PostgreSQL と互換性がある](working-with-postgresql-compatibility.md)ように設計されており、ACID トランザクション、セカンダリインデックス、結合、標準 DML オペレーションなどのコアリレーショナル機能をサポートしています。既存の PostgreSQL アプリケーションのほとんどは、最小限の変更で Aurora DSQL に移行できます。
このセクションでは、フレームワークの互換性、移行パターン、アーキテクチャ上の考慮事項など、アプリケーションを Aurora DSQL に移行するための実用的なガイダンスを提供します。
## フレームワークと ORM の互換性
Aurora DSQL は標準の PostgreSQL ワイヤプロトコルを使用して、PostgreSQL ドライバーおよびフレームワークとの互換性を確保します。最も一般的な ORM は、最小限の変更または変更なしで Aurora DSQL で動作します。リファレンス実装と利用可能な ORM 統合については、「[Aurora DSQL アダプターとダイアレクト](aws-sdks.md#aurora-dsql-adapters)」を参照してください。
## 一般的な移行パターン
PostgreSQL から Aurora DSQL に移行する場合、一部の機能の動作が異なったり、代替構文が使用されたりすることがあります。このセクションでは、一般的な移行シナリオに関するガイダンスを提供します。
### DDL オペレーションの代替方法
Aurora DSQL は、従来の PostgreSQL DDL オペレーションに代わる最新の操作を提供します。
**インデックスの作成**
ノンブロッキングインデックスの作成には、`CREATE INDEX` の代わりに `CREATE INDEX ASYNC` を使用します。
**ベネフィット:** 大規模なテーブルでのダウンタイムなしでインデックスを作成できます。
**データの削除**
`TRUNCATE` ではなく `DELETE FROM table_name` を使用します。
**代替方法:** テーブルの完全な再作成には、`DROP TABLE` に続いて `CREATE TABLE` を使用します。
**システム設定**
Aurora DSQL は完全に管理されているため、設定はワークロードパターンに基づいて自動的に処理されます。AWS マネジメントコンソールまたは API を使用して、クラスター設定を管理します。
**ベネフィット:** データベースのチューニングやパラメータ管理は必要ありません。
### スキーマ設計パターン
Aurora DSQL との互換性のために、以下の一般的な PostgreSQL パターンを適応させます。
**参照整合性パターン**
Aurora DSQL はテーブルの関係と `JOIN` オペレーションをサポートしています。参照整合性を保つには、アプリケーションレイヤーに検証を実装します。この設計は、アプリケーションレイヤーの検証により柔軟性が向上し、カスケードオペレーションによるパフォーマンスのボトルネックを回避する最新の分散データベースパターンと一致しています。
**パターン:** 一貫した命名規則、検証ロジック、トランザクション境界を使用して、アプリケーションレイヤーに参照整合性チェックを実装します。多くの大規模なアプリケーションでは、エラー処理とパフォーマンスをより適切に制御するためにこのアプローチが好まれます。
**一時的なデータ処理**
一時テーブルの代わりに、CTE、サブクエリ、またはクリーンアップロジックを備えた通常のテーブルを使用します。
**代替方法:** セッション固有の名前を持つテーブルを作成し、アプリケーション内でクリーンアップします。
## アーキテクチャの違いを理解する
Aurora DSQL の分散サーバーレスアーキテクチャは、いくつかの点で従来の PostgreSQL と意図的に異なります。これらの違いにより、Aurora DSQL の主なベネフィットであるシンプルさとスケールが実現されます。
### 簡素化されたデータベースモデル
**クラスターごとに単一のデータベース**
Aurora DSQL には、クラスターごとに `postgres` という名前の組み込みデータベースが 1 つ用意されています。
**移行のヒント:** アプリケーションで複数のデータベースを使用する場合は、論理的に分離するために個別の Aurora DSQL クラスターを作成するか、単一のクラスター内でスキーマを使用します。
**一時テーブルはありません**
一時的なデータ処理には、共通テーブル式 (CTE) とサブクエリを使用する必要があります。これにより、複雑なクエリの柔軟な代替手段が提供されます。
**代替方法:** 一時的な結果セットには `WITH` 句を使用した CTE を使用するか、セッション固有のデータ用に一意の名前を持つ通常のテーブルを使用します。
**Automatic Storage Management**
Aurora DSQL により、テーブルスペースと手動のストレージ管理が不要になります。ストレージは、データパターンに基づいて自動的にスケーリングおよび最適化されます。
**ベネフィット:** ディスク容量のモニタリング、ストレージ割り当ての計画、テーブルスペース設定の管理を行う必要がありません。
### 最新のアプリケーションパターン
Aurora DSQL は、メンテナンス性とパフォーマンスを向上させる最新のアプリケーション開発パターンを奨励します。
**データベーストリガーではなくアプリケーションレベルのロジック**
トリガーのような機能を実現するには、アプリケーションレイヤーにイベント駆動型ロジックを実装します。
**移行戦略:** トリガーロジックをアプリケーションコードに移動し、EventBridge などの AWS のサービスでイベント駆動型アーキテクチャを使用するか、アプリケーションのログ記録を使用して監査証跡を実装します。
**データ処理用の SQL 関数**
Aurora DSQL は SQL ベースの関数をサポートしていますが、PL/pgSQL などの手続き型言語はサポートしていません。
**代替方法:** データ変換に SQL 関数を使用するか、複雑なロジックをアプリケーションレイヤーまたは AWS Lambda 関数に移動します。
**悲観的ロックではなく最適化されたオプティミスティック同時実行制御**
Aurora DSQL は、従来のデータベースロックメカニズムとは異なるロックフリーアプローチであるオプティミスティック同時実行制御 (OCC) を使用します。Aurora DSQL では、他のトランザクションをブロックするロックを取得する代わりに、トランザクションをブロックせずに続行し、コミット時に競合を検出できます。これにより、デッドロックが解消され、遅いトランザクションが他のオペレーションをブロックすることがなくなります。
**主な違い:** 競合が発生すると、Aurora DSQL はトランザクションをロックまで待機させるのではなく、シリアル化エラーを返します。これには、従来のデータベースでのロックタイムアウトの処理と同様に、アプリケーションで再試行ロジックを実装する必要がありますが、ブロッキング待機が発生するのではなく、競合はすぐに解決されます。
**設計パターン:** 再試行メカニズムを使用してべき等トランザクションロジックを実装します。ランダムなプライマリキーを使用し、キー範囲全体に更新を分散することで、競合を最小限に抑えるスキーマを設計します。詳細については、「[Aurora DSQL での同時実行制御](working-with-concurrency-control.md)」を参照してください。
**関係と参照整合性**
Aurora DSQL は、` JOIN ` オペレーションを含むテーブル間の外部キー関係をサポートします。参照整合性を保つには、アプリケーションレイヤーに検証を実装します。参照整合性の適用は重要ですが、カスケードオペレーション (カスケード削除など) は予期しないパフォーマンスの問題を引き起こす可能性があります。例えば、1,000 行の明細項目を含む注文を削除すると、1,001 行のトランザクションになります。このため、多くのお客様は外部キーの制約を回避します。
**設計パターン:** アプリケーションレイヤーに参照整合性チェックを実装し、結果整合性パターンを使用するか、データ検証に AWS のサービスを活用します。
### 運用の簡素化
Aurora DSQL は、従来のデータベースメンテナンスタスクの多くを排除し、運用上のオーバーヘッドを削減します。
**手動メンテナンスは不要**
Aurora DSQL は、ストレージの最適化、統計収集、パフォーマンス調整を自動的に管理します。`VACUUM` のような従来のメンテナンスコマンドはシステムによって処理されます。
**ベネフィット:** データベースのメンテナンスウィンドウ、バキュームスケジュール、システムパラメータの調整が不要になります。
**自動パーティショニングとスケーリング**
Aurora DSQL は、アクセスパターンに基づいてデータを自動的にパーティション化して分散します。最適なディストリビューションのために、UUID またはアプリケーション生成 ID を使用します。
**移行のヒント:** 手動パーティショニングロジックを削除し、Aurora DSQL でデータ分散を処理できるようにします。最適なディストリビューションのために、UUID またはアプリケーション生成 ID を使用します。アプリケーションで連続した識別子が必要な場合は、「[シーケンスと ID 列](sequences-identity-columns.md)」を参照してください。
# AI ツールによるエージェント移行
AI コーディングエージェントは、スキーマを分析し、コードを変換し、組み込みの安全チェックを使用して DDL 移行を実行することで、Aurora DSQL への移行を加速できます。
## Kiro を使用した移行
[Kiro](https://kiro.dev/) などのコーディングエージェントは、PostgreSQL コードを分析して Aurora DSQL に移行するのに役立ちます。
+ **スキーマ分析:** 既存のスキーマファイルをアップロードし、Kiro に潜在的な互換性の問題を特定して代替案を提案してもらいます
+ **コード変換:** アプリケーションコードを提供し、トリガーロジックのリファクタリング、シーケンスの UUID への置き換え、トランザクションパターンの変更などを Kiro に依頼します
+ **移行計画:** Kiro に特定のアプリケーションアーキテクチャに基づいたステップバイステップの移行計画の作成を依頼します
+ **DDL 移行:** 安全チェックとユーザー検証が組み込まれたテーブル再作成パターンを使用してスキーマ変更を実行します
**プロンプトの例:**
```
"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"
"Drop the legacy_status column from the orders table"
"Change the price column from VARCHAR to DECIMAL in the products table"
```
## テーブルの再作成による DDL 移行
Aurora DSQL MCP サーバーで AI エージェントを使用する場合、特定の ALTER TABLE オペレーションでは、データを安全に移行する*テーブル再作成パターン*が使用されます。エージェントは複雑な処理を引き受けながら、各ステップで常に情報を提供します。
次のオペレーションでは、テーブルの再作成パターンが使用されます。
| Operation | アプローチ |
| --- | --- |
| DROP COLUMN | 新しいテーブルから列を除外する |
| ALTER COLUMN TYPE | 移行中にデータ型をキャストする |
| ALTER COLUMN SET/DROP NOT NULL | 新しいテーブル定義の制約を変更する |
| ALTER COLUMN SET/DROP DEFAULT | 新しいテーブル定義でデフォルトを定義する |
| ADD/DROP CONSTRAINT | 新しいテーブルに制約を追加または削除する |
| MODIFY PRIMARY KEY | 一意性検証を備えた新しい PK を定義する |
| 列の分割/結合 | SPLIT\$1PART、SUBSTRING、または CONCAT を使用する |
次の ALTER TABLE オペレーションは、テーブルの再作成なしで直接サポートされています。
+ `ALTER TABLE ... RENAME COLUMN` – 列名の変更
+ `ALTER TABLE ... RENAME TO` – テーブル名の変更
+ `ALTER TABLE ... ADD COLUMN` – 新しい列を追加する
**安全機能:** DDL 移行を実行するときに、AI エージェントは移行計画を提示し、データの互換性を検証し、行数を確認し、DROP TABLE などの破壊的な操作を行う前に明示的な承認をリクエストします。
**バッチ移行:** 3,000 行を超えるテーブルの場合、エージェントはトランザクション制限内に収まるように 500～1,000 行単位で移行を自動的にバッチ処理します。
## Aurora DSQL MCP サーバー
Aurora DSQL モデルコンテキストプロトコル (MCP) サーバーを使用すると、AI アシスタントが Aurora DSQL クラスターに直接接続し、Aurora DSQL ドキュメントを検索できるようになります。これにより、AI は次のことが可能になります。
+ 既存のスキーマを分析し、移行の変更を提案します
+ テーブル再作成パターンを使用して DDL 移行を実行する
+ 移行中にクエリをテストし、互換性を検証します
+ 最新の Aurora DSQL ドキュメントに基づいて、正確で最新のガイダンスを提供します
AI アシスタントで Aurora DSQL MCP サーバーを使用するには、[Aurora DSQL MCP サーバー](SECTION_aurora-dsql-mcp-server.md)のセットアップ手順を参照してください。
## PostgreSQL 互換性に関する Aurora DSQL の考慮事項
Aurora DSQL には、分散アーキテクチャ、サーバーレスオペレーション、自動スケーリングを可能にするセルフマネージド PostgreSQL とは異なる機能サポートがあります。ほとんどのアプリケーションは、これらの違いを変更せずにそのまま動作します。
一般的な考慮事項については、「[Amazon Aurora DSQL の使用に関する考慮事項](considerations.md)」を参照してください。クォータと制限については、「[Amazon Aurora DSQL のクラスタークォータとデータベース制限](CHAP_quotas.md)」を参照してください。
+ Aurora DSQL は、クラスターごとに `postgres` という名前の単一の組み込みデータベースを使用します。論理的に分離するには、個別の Aurora DSQL クラスターを作成するか、単一のクラスター内でスキーマを使用します。
+ `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 は、スキーマレベルの許可を通じてアクセス許可を管理します。管理者ユーザーは `CREATE SCHEMA` を使用してスキーマを作成し、`GRANT USAGE ON SCHEMA` を使用してアクセス権を付与します。管理者ユーザーはパブリックスキーマ内のオブジェクトを管理しますが、管理者以外のユーザーはユーザーが作成したスキーマ内にオブジェクトを作成して、所有権の境界を明確にします。詳細については、「[データベースで SQL を使用するためのデータベースロールの許可](using-database-and-iam-roles.md#using-database-and-iam-roles-custom-database-roles-sql)」を参照してください。
## 移行に関してサポートが必要ですか。
移行に不可欠であるにもかかわらず、Aurora DSQL で現在サポートされていない機能に遭遇した場合、「[Amazon Aurora DSQL に関するフィードバックの提供](providing-feedback.md)」を参照して AWS とフィードバックを共有する方法を確認してください。