はじめに

ローカルのDocker環境で開発したアプリケーションをAWSにデプロイする際、データベースの選択は非常に重要な決断です。「MySQL vs PostgreSQL」という古くから続く論争に、今回はAWSという具体的な文脈から実践的な答えを出していきます。

AWSでの選択肢

MySQL系

Amazon RDS for MySQL
Amazon Aurora MySQL互換

PostgreSQL系

Amazon RDS for PostgreSQL
Amazon Aurora PostgreSQL互換

コスト比較

RDS MySQL vs RDS PostgreSQL

結論：ほぼ同等

同じインスタンスタイプなら料金は同一
db.t3.micro: 約$12.41/月（東京リージョン）
ストレージ料金も同じ（$0.138/GB/月）

Aurora MySQL vs Aurora PostgreSQL

結論：PostgreSQLがわずかに高い

Aurora MySQL: $0.12/ACU時間
Aurora PostgreSQL: $0.13/ACU時間（約8%高い）
I/O料金は同じ（$0.24/100万リクエスト）

💡 ポイント: Auroraのサーバーレスv2を使えば、両方とも最小0.5ACUから自動スケーリング可能

パフォーマンス比較

読み取り性能

Aurora MySQL

シンプルなクエリで最大5倍のスループット
大量の同時接続に強い
キャッシュヒット率が高い

Aurora PostgreSQL

複雑なクエリで優位
分析系処理が高速
パラレルクエリ機能が強力

書き込み性能

実測値の傾向

小規模（〜1000 TPS）: ほぼ同等
中規模（1000-5000 TPS）: Aurora MySQL有利
大規模（5000+ TPS）: Aurora PostgreSQL（適切なチューニング後）

全文検索機能の真実

MySQL（InnoDB）

-- 実はMySQLも全文検索可能！
CREATE FULLTEXT INDEX idx_content ON articles(content);
SELECT * FROM articles WHERE MATCH(content) AGAINST('検索語');

問題点：

日本語はデフォルトでngram（2文字）のみ
形態素解析なし
カスタマイズが困難

PostgreSQL

-- 日本語全文検索（pg_bigm使用）
CREATE EXTENSION pg_bigm;
CREATE INDEX idx_content ON articles USING gin(content gin_bigm_ops);
SELECT * FROM articles WHERE content LIKE '%検索語%';

メリット：

pg_bigm、PGroongaなど選択肢が豊富
日本語対応が優秀
カスタム辞書作成可能

🎯 結論: 日本語全文検索ならPostgreSQL一択

AWSマネージドサービスの恩恵

共通のメリット

自動バックアップ（最大35日間）
ポイントインタイムリカバリ
マルチAZ構成
自動パッチ適用
CloudWatchメトリクス

MySQL特有の利点

Aurora Global Databaseが安定
ProxySQL統合が簡単
WordPress等のCMS対応が完璧

PostgreSQL特有の利点

拡張機能が豊富（PostGIS、pg_stat_statements等）
Aurora PostgreSQLでBabelfish（SQL Server互換）
機械学習拡張（pgvector）対応

移行の難易度

Docker → AWS RDS MySQL

# docker-compose.yml
mysql:
  image: mysql:8.0
  environment:
    MYSQL_ROOT_PASSWORD: password

↓

# AWS CLI
aws rds create-db-instance \
  --db-instance-identifier myapp-mysql \
  --engine mysql \
  --engine-version 8.0.35

移行時間: 1-2時間（データ量による）

Docker → AWS RDS PostgreSQL

# docker-compose.yml
postgres:
  image: postgres:15
  environment:
    POSTGRES_PASSWORD: password

↓

# AWS CLI
aws rds create-db-instance \
  --db-instance-identifier myapp-postgres \
  --engine postgres \
  --engine-version 15.4

移行時間: 1-2時間（同上）

実践的な選択フローチャート

スタート
├─ 既存システムがある？
│  ├─ Yes → そのDBを継続使用
│  └─ No ↓
├─ 日本語全文検索が必須？
│  ├─ Yes → PostgreSQL
│  └─ No ↓
├─ 複雑な分析クエリが多い？
│  ├─ Yes → PostgreSQL
│  └─ No ↓
├─ WordPress/EC系CMS使用？
│  ├─ Yes → MySQL
│  └─ No ↓
├─ 地理空間データを扱う？
│  ├─ Yes → PostgreSQL（PostGIS）
│  └─ No ↓
└─ デフォルト選択 → MySQL（エコシステムが広い）

具体的なユースケース別推奨

MySQL推奨

ECサイト（Magento、WooCommerce）
ブログ/CMS（WordPress、Drupal）
シンプルなWebアプリ
マイクロサービスのトランザクションDB

PostgreSQL推奨

データ分析基盤
地図/位置情報サービス
日本語検索エンジン
時系列データ処理（TimescaleDB）
AI/MLアプリケーション（pgvector）

コスト最適化のコツ

両DB共通

Reserved Instances: 1年/3年契約で最大72%割引
Aurora Serverless v2: 使用量に応じた課金
適切なインスタンスサイジング: CloudWatch確認
不要なスナップショット削除

MySQL特有

Query Cache活用でインスタンスサイズ削減
Read Replicaの地理的配置最適化

PostgreSQL特有

適切なautovacuum設定でI/O削減
パーティショニングでコスト最適化

まとめ：2024年の結論

PostgreSQLを選ぶべき場合

日本語全文検索が重要
複雑なデータ分析が必要
最新技術（AI、地理情報）活用
ベンダーロックインを避けたい

MySQLを選ぶべき場合

既存のMySQL資産がある
CMSやECパッケージ利用
シンプルで高速なCRUD処理
豊富なコミュニティサポート重視

個人的な推奨

新規プロジェクトなら Aurora PostgreSQL Serverless v2 を推奨します。理由：

スケーラビリティが優秀
日本語対応が良好
将来の拡張性が高い
初期コストが低い（0.5ACUから）

最後に

「MySQL vs PostgreSQL」という不毛な戦争ではなく、要件に応じた適切な選択が重要です。AWSのマネージドサービスを使えば、どちらを選んでも運用負荷は大幅に軽減されます。

まずは小さく始めて、必要に応じてスケールアップ。これがクラウドネイティブな開発の醍醐味ですね。

執筆者

株式会社ユーコン
CEO 植村圭志
http://ucon.net/