データベース移行（Oracle→PostgreSQL/MySQL）の費用相場｜ライセンスコスト70%削減の移行ガイド【2026年版】

「Oracle Databaseのライセンス更新見積もりを見て、思わず二度見した」。そんな経験は、中堅企業の情シス担当者なら一度はあるはずだ。Oracle Database Enterprise Editionのライセンスは、Processor単位で500万円超。これにサポート費用が年額22%加算される。5年間のTCOで計算すると、ライセンスとサポートだけで数千万円規模の支出になる。

Gartner「DBMS Market Share Report 2025」によると、PostgreSQLの企業採用率は2020年の34%から2025年には52%へ急伸した。背景にあるのは、PostgreSQLの機能成熟とOracleのライセンスコスト上昇だ。実際に、Oracle→PostgreSQL移行で年間ライセンスコストを70%削減した事例は珍しくない。

本記事では、Oracle DatabaseからPostgreSQLまたはMySQLへの移行について、費用相場の内訳、技術的な移行手順、主要ツールの使い分け、失敗を避けるためのポイントを網羅的に解説する。

Oracle移行を検討すべき5つのタイミング
移行先の選定：PostgreSQL vs MySQL
費用相場の全体像
移行の5フェーズと技術的ポイント
主要移行ツールの比較と使い分け
ライセンスコスト70%削減のシミュレーション
移行プロジェクトで失敗しないための7つの注意点
補助金の活用
まとめ
FAQ
付録：Oracle→PostgreSQL移行チェックリスト

1. Oracle移行を検討すべき5つのタイミング

以下のいずれかに該当する場合、Oracle Databaseからの移行を本格的に検討する価値がある。

ライセンス更新の1年前。 Oracle Databaseのサポート契約は年次更新であり、更新時に値上げされるケースが増えている。更新の1年前に移行の可否を検討し始めれば、スケジュールに余裕を持てる。

サーバーのリプレイス時期。 オンプレミスのDBサーバーを更新するタイミングは、データベースエンジンごと切り替える最良の機会だ。ハードウェア更新とDB移行を同時に進めることで、二重のコスト削減が実現できる。

クラウド移行の計画時。 AWS、Azure、GCPへのシステム移行を進める場合、Oracleをそのままクラウドに載せるとBYOL（Bring Your Own License）の制約やクラウド上のOracle課金体系の複雑さに直面する。クラウドネイティブなPostgreSQLやMySQLに移行するほうが、長期的なTCOで有利になるケースが多い。

DX推進・モダナイゼーション計画時。 マイクロサービス化やAPI化を進める際、Oracle固有のPL/SQL資産が足かせになる。モダナイゼーションのタイミングでDB移行を組み込むと、アプリ改修と並行して進められる。

Oracle技術者の退職・不足時。 Oracle DBAの人材市場は縮小傾向にある。属人化した運用を脱し、コミュニティが活発なPostgreSQLに切り替えることで、運用体制のサステナビリティを確保できる。

2. 移行先の選定：PostgreSQL vs MySQL

Oracle Databaseからの移行先として、PostgreSQLとMySQLの2択が現実的な選択肢だ。

比較項目	PostgreSQL	MySQL
Oracle互換性	高い（PL/pgSQL ≒ PL/SQL）	低い（ストアドの書き換え大）
データ型の互換性	NUMBER→NUMERIC、VARCHAR2→VARCHAR	NUMBER→DECIMAL（精度に注意）
パーティショニング	宣言的パーティショニング対応	対応（RANGEが主流）
JSON対応	JSONB型で高速検索	JSON型（5.7以降）
Window関数	完全対応	8.0以降で対応
マテリアライズドビュー	ネイティブ対応	非対応（手動実装が必要）
ライセンス	PostgreSQL License（完全無料）	GPL v2（商用利用注意）
クラウドマネージド	AWS Aurora/RDS、Azure、Cloud SQL	AWS Aurora/RDS、Azure、Cloud SQL
企業導入実績	金融・官公庁で増加中	Web系・SaaS企業で多い
コミュニティ規模	急成長中	大規模・安定

結論：Oracle移行にはPostgreSQLが第一候補

Oracle Databaseからの移行では、PostgreSQLを第一候補として推奨する。理由は3つある。

PL/SQL→PL/pgSQLの変換コストが低い。 構文の類似度が高く、ora2pgによる自動変換率が70-90%に達する。MySQLへの移行では、ストアドプロシージャを全面書き換えする必要があり、工数が2-3倍になる。

データ型の互換性が高い。 OracleのNUMBER型はPostgreSQLのNUMERICにほぼそのまま変換できる。MySQLのDECIMAL型では精度とスケールの指定が必要で、変換時にデータ損失のリスクがある。

エンタープライズ機能の充実。 マテリアライズドビュー、テーブル継承、高度なインデックス（GiST、GIN）など、Oracle環境で使っていた機能の多くがPostgreSQLにも存在する。

ただし、アプリケーション側がMySQL前提で設計されている場合（例：既存WebアプリがMySQL用のORMに依存している場合）は、MySQLへの移行のほうがアプリ改修コストが低くなることもある。

3. 費用相場の全体像

Oracle→PostgreSQL/MySQL移行の費用は、データベースの規模と複雑性によって大きく変動する。以下に、規模別の費用相場を示す。

3-1. フェーズ別費用

フェーズ	内容	費用相場	期間
アセスメント	現状調査、移行可否判定、概算見積	100万〜300万円	2〜4週間
移行設計	スキーマ変換設計、移行方式決定	100万〜400万円	2〜6週間
移行実装	スキーマ変換、PL/SQL変換、データ移行開発	200万〜800万円	1〜3ヶ月
テスト	機能テスト、性能テスト、データ検証	100万〜300万円	1〜2ヶ月
本番移行・安定化	カットオーバー、移行後監視	50万〜200万円	2〜4週間
合計	500万〜2,000万円	3〜8ヶ月

3-2. 規模別の費用目安

規模	テーブル数	ストアド数	データ量	費用目安	期間
小規模	〜50	〜20	〜10GB	500万〜800万円	3〜4ヶ月
中規模	50〜200	20〜100	10〜100GB	800万〜1,500万円	4〜6ヶ月
大規模	200〜	100〜	100GB〜	1,500万〜2,000万円超	6〜8ヶ月

3-3. 費用を左右する5つの変動要因

PL/SQLの量と複雑性。 移行費用の30〜50%はPL/SQL→PL/pgSQLの変換に集中する。Oracle固有のパッケージ（DBMS_OUTPUT、UTL_FILE、DBMS_LOB等）を多用している場合、手動変換の工数が大幅に増加する。

Oracle固有機能の使用状況。 Database Link、Oracle Text、Oracle Spatial、Advanced Queuing、Flashback Queryなど、Oracle固有の機能を使用している場合、PostgreSQL側での代替実装が必要になり、追加コストが発生する。

データ量とダウンタイム許容時間。 データ量が100GBを超える場合、データ移行の方式選定（オフライン/オンライン）が費用に影響する。ダウンタイムを数時間以内に抑える必要がある場合、AWS DMSなどのCDCツールが必要になり、費用が上積みされる。

アプリケーション側の改修範囲。 SQLの直書き（ネイティブSQL）が多いアプリケーションは、ORM経由のアプリケーションよりも改修工数が多い。Oracle固有のSQL構文（CONNECT BY、ROWNUM、NVL、DECODE等）の書き換えが必要になる。

テスト範囲と品質要件。 金融系や基幹システムでは、全SQLの回帰テストと性能テストが要求される。テストの自動化環境の構築を含めると、テスト費用が全体の20〜30%を占めることもある。

4. 移行の5フェーズと技術的ポイント

フェーズ1：アセスメント（2〜4週間）

現行のOracle環境を詳細に調査し、移行の可否と概算工数を算出する。

調査項目一覧

調査項目	確認内容	ツール
スキーマ構造	テーブル数、カラム数、データ型、制約	ora2pg --test
PL/SQL資産	パッケージ数、プロシージャ数、行数	ora2pg --estimate
Oracle固有機能	DB Link、Oracle Text、Spatial等の使用有無	AWS SCT Assessment Report
SQL互換性	Oracle固有SQL構文の使用箇所	AWS SCT
データ量	テーブル別のサイズ、増加率	Oracle DBAビュー
性能要件	ピーク時のクエリ数、レスポンス要件	AWR/ADDM

ora2pgの`--estimate`オプションを実行すると、移行難易度がA（容易）〜C（困難）で自動判定される。この結果をもとに、概算工数を算出する。

フェーズ2：スキーマ変換（2〜4週間）

OracleのスキーマをPostgreSQLに変換する。主要な変換ポイントは以下の通り。

データ型の変換マッピング

Oracle	PostgreSQL	変換時の注意点
NUMBER(p,s)	NUMERIC(p,s)	精度・スケールをそのまま移行可能
NUMBER（精度指定なし）	NUMERIC または DOUBLE PRECISION	用途に応じて使い分け
VARCHAR2(n)	VARCHAR(n)	バイト長→文字長の違いに注意
DATE	TIMESTAMP	OracleのDATEは秒まで保持する
CLOB	TEXT	PostgreSQLのTEXTに容量制限はない
BLOB	BYTEA	大容量はLargeObjectも検討
RAW	BYTEA	バイナリデータの変換
SEQUENCE	SEQUENCE	構文は類似、現在値の移行を忘れずに

制約とインデックスの変換

OracleのBitmapインデックスはPostgreSQLには存在しないため、B-treeインデックスまたはGINインデックスへの変換が必要。ファンクションベースインデックスは、PostgreSQLの式インデックスに変換する。パーティションテーブルは、PostgreSQLの宣言的パーティショニングで再定義する。

フェーズ3：PL/SQL→PL/pgSQL変換（1〜3ヶ月）

移行工数の中で最も大きな割合を占めるフェーズだ。

自動変換が可能な範囲（70-90%）

ora2pgを使用すると、以下の変換は自動で処理される。

基本的なPL/SQL構文（IF/THEN/ELSE、LOOP、CURSOR等）
パラメータのIN/OUT宣言
例外処理（EXCEPTION WHEN）
基本的なSQL文のラップ

手動変換が必要な範囲（10-30%）

以下はora2pgでは完全に変換できず、手動での対応が必要。

Oracle固有構文	PostgreSQL対応
CONNECT BY / START WITH	WITH RECURSIVE（再帰CTE）
ROWNUM	ROW_NUMBER() OVER() または LIMIT/OFFSET
NVL(a, b)	COALESCE(a, b)
DECODE(a, b, c, d)	CASE WHEN a = b THEN c ELSE d END
SYSDATE	CURRENT_TIMESTAMP または NOW()
(+) 外部結合構文	LEFT/RIGHT JOIN（標準SQL構文）
DBMS_OUTPUT.PUT_LINE	RAISE NOTICE
UTL_FILE	pg_read_file / COPY文 / 外部プログラム
DBMS_LOB	ラージオブジェクト関数
DBMS_JOB / DBMS_SCHEDULER	pg_cron 拡張

SQL互換性の対応

アプリケーション内に埋め込まれたSQL文も移行対象になる。特にOracle固有の構文が多い場合は、アプリケーション改修の工数がかさむ。ORM（Hibernate、MyBatis等）を使用している場合は、Dialect設定の変更で対応できるケースが多い。ネイティブSQLを直書きしている箇所は、1つずつ書き換えが必要だ。

フェーズ4：データ移行（2〜4週間）

データ移行は「全量移行」と「差分同期」の2段階で進める。

全量移行の方式

方式	ツール	特徴	適するケース
ダンプ&ロード	ora2pg	シンプル、確実	10GB以下、長時間停止可
ETL	AWS DMS	CDC対応、並列処理	10GB超、短時間停止要件
CSV経由	Oracle SQL*Plus + PostgreSQL COPY	簡易、手動制御	テーブル単位の部分移行

データ整合性の検証

移行後の検証は必須だ。以下の3段階で確認する。

レコード数照合。 全テーブルのレコード数を移行元と移行先で比較。
チェックサム照合。 主要テーブルの主キーとハッシュ値で一致を確認。
業務フロー検証。 アプリケーションを通じた主要業務シナリオの実行で正常動作を確認。

フェーズ5：テストと本番切り替え（1〜2ヶ月）

テスト計画のポイント

テスト種別	内容	合格基準の例
機能テスト	全CRUD操作、バッチ処理の正常動作	全テストケースPass
SQL回帰テスト	移行前後のSQL結果一致	一致率100%
性能テスト	ピーク時クエリのレスポンス	移行前比120%以内
負荷テスト	同時接続数、TPS	SLA基準をクリア
フェイルオーバーテスト	障害時の切り替え	RTO/RPO基準をクリア

性能テストでは、Oracleのオプティマイザとは異なるPostgreSQLの実行計画に注意が必要だ。EXPLAINで実行計画を確認し、必要に応じてインデックスの追加やクエリのチューニングを行う。

5. 主要移行ツールの比較と使い分け

ora2pg

項目	内容
種別	OSS（Perlベース）
費用	無料
対応	Oracle→PostgreSQL特化
主な機能	スキーマ変換、PL/SQL変換、データ移行、移行難易度評価
自動変換率	70〜90%（プロジェクトの複雑性による）
向いているケース	PostgreSQLへの移行全般、アセスメント段階の評価

ora2pgはOracle→PostgreSQL移行のデファクトスタンダードツールだ。`ora2pg --test`でデータベースの移行難易度を自動評価でき、アセスメント段階から活用できる。スキーマ変換、PL/SQL変換、データ移行を一気通貫で処理できる点が強い。

AWS Schema Conversion Tool（SCT）

項目	内容
種別	AWS提供（無料）
費用	無料（AWSアカウント必要）
対応	Oracle→PostgreSQL/MySQL/Aurora等
主な機能	スキーマ変換、SQL変換、移行評価レポート
自動変換率	80〜95%（スキーマ）、60〜80%（PL/SQL）
向いているケース	AWS環境への移行、GUIベースの変換作業

AWS SCTはGUIで操作できるため、変換結果を視覚的に確認しやすい。Migration Assessment Reportで変換できない項目が一覧表示され、手動対応が必要な箇所を把握しやすい。AWS環境への移行を前提としている場合は第一選択肢になる。

AWS Database Migration Service（DMS）

項目	内容
種別	AWSマネージドサービス
費用	レプリケーションインスタンス課金（時間単位）
対応	Oracle→PostgreSQL/MySQL/Aurora等
主な機能	データ移行（全量＋CDC差分同期）
向いているケース	ダウンタイム最小化が必要な大規模移行

AWS DMSはCDC（Change Data Capture）に対応しており、移行元のOracleを稼働させたまま差分データをリアルタイムで同期できる。切り替え時のダウンタイムを数分〜数十分に抑えられるため、24時間稼働のシステムに適している。

ツール選定のフローチャート

移行先がAWS上のPostgreSQL/Aurora？ → AWS SCT + AWS DMS
移行先がオンプレミスのPostgreSQL？ → ora2pg（スキーマ＋PL/SQL＋データ）
移行先がMySQL/Aurora MySQL？ → AWS SCT + AWS DMS
ダウンタイムを最小化したい？ → AWS DMS（CDC機能）
アセスメントだけ先に実施したい？ → ora2pg --test + AWS SCT Assessment

6. ライセンスコスト70%削減のシミュレーション

Oracle DatabaseからPostgreSQLに移行した場合の、5年間のTCO比較を示す。

ケース：中堅企業（DBサーバー2台、Enterprise Edition、Standard Support）

移行前：Oracle環境の5年TCO

項目	年額	5年合計
Oracle EE ライセンス（2Processor × 2台）	—	2,200万円（購入済み）
Oracle Support（22%/年）	484万円	2,420万円
DBサーバー（ハードウェア保守）	100万円	500万円
Oracle DBA 運用（外注0.5人月/月）	360万円	1,800万円
バックアップ・監視ツール	50万円	250万円
合計	7,170万円

移行後：PostgreSQL環境の5年TCO

項目	年額	5年合計
PostgreSQLライセンス	0円	0円
AWS Aurora PostgreSQL（db.r6g.xlarge × 2）	約300万円	1,500万円
移行プロジェクト費用	—	1,200万円（初年度）
PostgreSQL運用（外注0.3人月/月）	216万円	1,080万円
監視・バックアップ（CloudWatch等）	30万円	150万円
合計	3,930万円

削減効果

項目	金額
5年TCO削減額	3,240万円
削減率	45%
ライセンス＋サポート費用の削減率	約70%
移行費用の回収期間	約1.5年

ライセンス費用とサポート費用に限定すると、Oracle環境では5年間で4,620万円（ライセンス2,200万円＋サポート2,420万円）であるのに対し、PostgreSQL環境ではライセンス0円＋Aurora利用料1,500万円 = 1,500万円となり、約70%の削減になる。移行プロジェクト費用1,200万円を含めても、2年目以降は年間600万円以上のコスト削減効果が継続する。

7. 移行プロジェクトで失敗しないための7つの注意点

注意点1：PL/SQL変換の工数を甘く見ない

ora2pgの自動変換率が80%と報告されても、残り20%の手動変換が全体工数の50%を占めることがある。特にOracle固有パッケージ（DBMS_*）を多用している環境では、手動変換の工数を十分に見積もること。アセスメントの段階でPL/SQLの行数と使用しているOracle固有機能を正確に洗い出すことが重要だ。

注意点2：暗黙的な型変換に注意する

Oracleは暗黙的な型変換が寛容だ。例えば、文字列と数値の比較を自動変換してくれる。PostgreSQLは型に厳格で、暗黙的な型変換の範囲が狭い。移行後に「OracleではエラーにならなかったSQLがPostgreSQLでエラーになる」というケースが頻発する。全SQLの回帰テストが不可欠だ。

注意点3：文字コードの統一を事前に行う

Oracle環境でJA16SJISやJA16EUCを使用している場合、PostgreSQL（UTF-8）への変換時に文字化けが発生する可能性がある。移行前にOracle側でUTF-8への変換を済ませておくか、移行ツールの文字コード変換設定を慎重に行うこと。

注意点4：性能特性の違いを理解する

OracleのオプティマイザとPostgreSQLのオプティマイザは異なるアルゴリズムを使用している。Oracleで高速だったクエリがPostgreSQLで遅くなるケース、逆にPostgreSQLのほうが速くなるケースの両方がある。移行後の性能テストは必須であり、EXPLAIN ANALYZEを使った実行計画の確認と、必要に応じたインデックス再設計を行うこと。

注意点5：SYNONYMとDatabase Linkの代替を設計する

OracleのSYNONYM（シノニム）はPostgreSQLにはsearch_pathやビューで代替する。Database LinkはPostgreSQLのFDW（Foreign Data Wrapper）で代替するが、機能の完全互換ではないため、利用パターンごとに設計が必要だ。

注意点6：ロールバック計画を必ず用意する

本番切り替え後に重大な問題が発覚した場合のロールバック計画を事前に策定する。Oracle環境を最低2週間は維持し、いつでも切り戻せる状態にしておくこと。ロールバックの判断基準（どの指標がどの水準を超えたら切り戻すか）を事前に関係者間で合意しておく。

注意点7：段階的移行を検討する

全システムを一度に移行するビッグバン方式はリスクが高い。可能であれば、参照系システム→更新系システム→基幹システムの順に段階的に移行する。FDW（Foreign Data Wrapper）を使えば、PostgreSQLからOracleのテーブルを参照できるため、移行期間中の共存が可能だ。

8. 補助金の活用

Oracle→PostgreSQL移行は、以下の補助金の対象になる可能性がある。

補助金	対象経費	補助率	上限額
デジタル化・AI導入補助金2026	システム移行費用、クラウド利用料（最大2年）	1/2〜4/5	150万円
ものづくり補助金	DB移行を含むシステム刷新費用	1/2〜2/3	1,250万円
事業再構築補助金	DX推進に伴うシステム基盤刷新	1/2〜2/3	1,500万円

Oracle移行は「レガシーシステムの刷新」として補助金の申請要件に合致するケースが多い。移行費用が500万円以上の場合は、ものづくり補助金や事業再構築補助金の活用を検討する価値がある。

まとめ

Oracle DatabaseからPostgreSQL/MySQLへの移行は、ライセンスコストの構造的な削減と運用のモダナイゼーションを同時に実現できるプロジェクトだ。

項目	ポイント
移行先の第一候補	PostgreSQL（PL/SQL互換性・エンタープライズ機能が優位）
費用相場	アセスメント100〜300万円、移行全体500〜2,000万円
最大のコスト削減効果	ライセンス＋サポート費用を約70%削減
移行費用の回収期間	約1.5年（中堅企業の場合）
主要ツール	ora2pg（OSS）、AWS SCT（スキーマ変換）、AWS DMS（データ移行）
最大のリスク	PL/SQL変換の工数見積もり不足
推奨アプローチ	段階的移行（参照系→更新系→基幹系）

移行プロジェクトの成否は、アセスメントの精度で8割が決まる。ora2pgの自動評価やAWS SCTのAssessment Reportを活用し、PL/SQL資産の量と複雑性、Oracle固有機能の使用状況を正確に把握することが第一歩だ。GXO株式会社の開発事例はこちら。会社概要はこちら。

Oracle→PostgreSQL移行の無料アセスメント、実施中です

現在のOracle環境のPL/SQL資産量・Oracle固有機能の使用状況を調査し、移行の概算費用と期間をお見積もりします。ora2pgとAWS SCTを活用した客観的な評価レポートをお出しします。

Oracle移行の無料相談を申し込む

※ 営業電話はしません｜オンライン対応可｜相談だけでもOK

FAQ

Q1. Oracle→PostgreSQL移行にどのくらいの期間がかかりますか？

A1. テーブル50個以下・ストアドプロシージャ20個以下の小規模環境で3〜4ヶ月、100テーブル超・ストアド100個超の中〜大規模環境で6〜8ヶ月が目安だ。PL/SQLの量と複雑性が期間を最も大きく左右する。アセスメントを実施すれば、2〜4週間で精度の高い期間見積もりが得られる。

Q2. Oracle固有のPL/SQLが大量にありますが、移行は現実的ですか？

A2. 現実的だ。ora2pgの自動変換で70〜90%はカバーでき、残りを手動変換する。PL/SQLが10万行を超える大規模環境でも移行実績はある。ただし、Oracle固有パッケージ（DBMS_*、UTL_*）を多用している場合は工数が増える。アセスメントでPL/SQLの行数とOracle固有機能の使用箇所を正確に洗い出すことが重要だ。

Q3. 移行中にシステムを止める必要がありますか？

A3. AWS DMSのCDC機能を使えば、移行中もOracleを稼働させたままデータ同期が可能だ。最終切り替え時のダウンタイムは数分〜数十分に抑えられる。データ量が10GB以下で長時間の停止が許容できる場合は、オフライン移行（ダンプ&ロード）のほうがシンプルで確実だ。

Q4. 移行後のPostgreSQLの運用体制はどうすればよいですか？

A4. AWS Aurora PostgreSQLやRDS for PostgreSQLを使えば、バックアップ・パッチ適用・フェイルオーバーはAWSが自動管理する。Oracle DBAの専門知識がなくても運用できる。日常的な監視はCloudWatch、クエリチューニングはpg_stat_statementsで対応可能だ。Oracle DBAの外注費用（0.5人月/月）がPostgreSQL運用（0.3人月/月）に縮小するケースが多い。

Q5. MySQLへの移行ではなくPostgreSQLを推奨する理由は？

A5. Oracle→PostgreSQL移行ではPL/SQL→PL/pgSQLの自動変換率が高く、変換コストが低い。MySQLにはPL/SQLに相当するストアドプロシージャ言語がなく、全面書き換えが必要になる。また、マテリアライズドビュー、テーブル継承、高度なインデックスなど、Oracleユーザーが依存している機能の多くがPostgreSQLには存在する。ただし、アプリケーション側がMySQL前提で設計されている場合は、MySQLのほうが適するケースもある。

目次