システム設計でよく出るのが「DB はどれにするか」。SQL Server / PostgreSQL / MySQL / Oracle、さらにクラウドのマネージド（RDS / Azure SQL など）まで、候補が多い。
この記事では、RDB（リレーショナル DB）製品に絞って、ざっくり比較と要件から選ぶポイントを整理する。細かいベンチマークより、「現場で何を聞いてから決めるか」を優先する。
先に結論
- 業務システムでは多くの場合 RDB が第一候補
- 新規でよく並ぶのは SQL Server / PostgreSQL / MySQL（＋マネージド）
- Oracle は費用・習熟のハードルが高く、新規では比較的選ばれにくい（既存基幹の継続は別）
- SQLite は本番の共有 DB としては比較的選ばれない（埋め込み・ローカル向け）
- コストは 費用 と 習熟コスト の両方。既存資産があるなら移行コストも大きい
この記事の対象
対象は RDB 製品の比較と選定。SQL Server / PostgreSQL / MySQL / Oracle / SQLite と、それらをクラウドで使うときのマネージドの話まで。
主要 RDB のざっくり比較
比較はこの表にまとめる（詳細は各製品の節へ）。
| 製品 | 新規で選ばれやすさ | 費用（ライセンス代） | 習熟しやすさ・経験者の多さ | 向き |
|---|
| SQL Server | 高い（.NET 現場） | 商用ライセンス代がかかりやすい（PG/MySQL より高くなりやすい） | .NET / Windows 現場では習熟しやすい。経験者も見つけやすい | Windows / .NET とセット |
| PostgreSQL | 高い | エンジン自体は無償〜安い | 習熟しやすい部類。経験者は現場次第（クラウドでは増えつつある） | OSS・クラウド標準 |
| MySQL | 高い | エンジン自体は無償〜安い | Web 系では習熟しやすい。経験者も多い | Web・既存資産 |
| Oracle | 低い（比較的選ばれない） | いちばん高くなりやすい | 習熟しにくい。経験者は限られがち | 既存基幹の継続 |
| SQLite | 低い（本番共有では選ばれない） | エンジン費用はほぼかからない | 軽い用途なら習熟しやすい（本番共有DBの運用とは別） | 埋め込み・ローカル |
比較的選ばれない／選ばれにくいは、性能が悪いという意味ではない。費用・習熟・用途のミスマッチで、新規の第一候補になりにくい、という意味。
SQL Server
- .NET / EF Core / Windows 運用とセットで選ばれやすい
- 管理ツールや周辺（バックアップ、ジョブ）が揃っている
- クラウドなら Azure SQL / Amazon RDS for SQL Server など
- 費用: 新規に買うと 商用ライセンス代が PostgreSQL / MySQL より高くなりやすい。すでにライセンスや Azure Hybrid Benefit がある、チームが習熟済み、のときはトータルで妥当になりやすい
PostgreSQL
- OSS で機能が豊富。AWS / GCP / Azure いずれもマネージド選択肢が多い
- 「特定ベンダーに寄せたくない」ときの本命になりやすい
- 費用: エンジン自体のライセンス代は抑えやすい。ただし運用できる人がいないと、習熟・障害対応でトータルが高くつく
MySQL（と互換系）
- Web・スタートアップ・既存資産で多い
- Amazon Aurora MySQL 互換など、クラウド側の派生も多い
- 厳密な標準 SQL や一部の高度機能は、版と設定を確認
Oracle（新規では比較的選ばれにくい）
機能・基幹実績は厚いが、費用と専門性が高く、新規プロジェクトの第一候補としては比較的選ばれにくい。
- 選ばれる典型: 既に Oracle がある、基幹で継続が合理的、要件と予算がはっきりしている
- 選ばれにくい典型: 新規の中小〜中規模、少人数、コストを抑えたい、.NET/OSS 中心のチーム
SQLite（本番の共有 DB としては選ばれない）
アプリ組み込み、ローカル、テスト向け。複数ユーザーが同時に使う本番の共有 DB としては、比較的選ばれない（というより、用途が違う）。
クラウドで選ぶとき（マネージド）
「どのエンジンか」と「自前かマネージドか」は別軸。
- マネージド向き: 少人数運用、パッチ・バックアップを任せたい、可用性を製品機能で稼ぎたい。月額は見えやすい一方、深い障害はベンダー頼りになりやすい
- 自前向き: 特殊な設定・拡張、細部まで握りたい、規制で持ち出し制限がある。一見安く見えても、運用の習熟負担が大きい
例: Amazon RDS / Aurora、Azure SQL Database、Cloud SQL など。エンジンを決めたうえで、提供形態を選ぶ。
コストは「費用」と「習熟」の2つ
DB 選定で見落とされやすいのがコストの内訳。請求書に載る費用と、人が覚える習熟コストは別物。製品ごとの傾向は上の比較表を参照。
費用（お金）
費用は次の積み上げ。比較表の「費用」列は、主に①の話。
- エンジンのライセンス代
- 高い部類: Oracle（いちばん高くなりやすい）、SQL Server（商用ライセンスが必要になりやすい）
- 抑えやすい部類: PostgreSQL / MySQL（エンジン自体は無償〜安い。有償サポートは別）
- ほぼかからない: SQLite
- つまり SQL Server が費用面で PG/MySQL より安い、という意味ではない（新規購入ならむしろ高くなりやすい）
- クラウド利用料 … インスタンス、ストレージ、バックアップ、Multi-AZ など。どのエンジンでもかかる
- 人件費・外注 … 構築、移行、障害対応、チューニング
- 移行費用 … データ移行、アプリ改修、並行稼働。一度きりでも額が大きい
SQL Server がトータルで妥当になりやすいのは、すでにライセンスがある／Azure で既存ライセンスを使える／チームが習熟済みで移行しないとき。ゼロから新規に買う前提の「安さ」ではない。
習熟コスト（習熟しやすさ・経験者の多さ）
ここはお金の話ではなく、人が覚える・すでに覚えている人を確保する話。
- 習熟しやすさ … バックアップ、リストア、実行計画、ロックなどを、今のチームがどれくらい早く身につけられるか
- 経験者の多さ … 採用・異動・外注で「その DB に詳しい人」を見つけやすいか。深夜障害を任せられる人がいるか
- 現場の偏り … .NET / Windows なら SQL Server 経験者が多く、Web 系なら MySQL 経験者が多い、など。PostgreSQL はクラウド案件で増えつつある
- Oracle … 習熟のハードルが高く、経験者も限られがち。だから新規では比較的選ばれにくい
「PostgreSQL / MySQL はライセンス代が安い」は正しいことが多い。ただし 習熟できる人がいなければ、障害対応や学習でトータルが高くなる。逆に SQL Server / Oracle はライセンス代が高くても、チームがすでに習熟していて移行しないなら、トータルでは安くつくこともある。
要件に合わせた選定のポイント
製品名から入らず、要件を言語化してから当てる。
先に聞くこと
- 整合 … 更新の原子性・一貫性がどこまで必須か
- 習熟しやすさ・経験者の多さ … 今のチームが覚えられるか、採用・外注で詳しい人を確保できるか
- 既存資産 … 既に SQL Server / Oracle があるなら、移行コストが選定を支配する
- アプリのスタック … .NET 中心なら SQL Server、OSS スタックなら PostgreSQL / MySQL
- 運用体制 … 24h 対応できるか。できないならマネージド寄り
- 可用性・バックアップ … RPO / RTO、多重化の要否
- 費用 … ライセンス、クラウド課金、人件費、移行費用
- 制約 … オンプレ必須、特定クラウド指定、監査・暗号化要件
要件 → 寄せる先
- .NET / Windows 現場が中心 → SQL Server（＋ Azure SQL 等）
- OSS・クラウド標準で寄せたい → PostgreSQL
- Web 系・既存 MySQL 資産 → MySQL / Aurora MySQL 互換
- 基幹・既存 Oracle → Oracle 継続が第一候補（新規ゼロからの採用は比較的選ばれにくい）
- 少人数で可用性を稼ぎたい → マネージド RDB
- 埋め込み・ローカルのみ → SQLite（本番共有 DB としては選ばれない）
- 習熟済みの製品がある → 原則それを継続
- 費用は払えるが人が足りない → マネージド＋サポートを検討
決めてはいけないこと
- 流行だけで選ぶ … 運用できる人がいないと破綻する
- 「安いエンジン＝安い」 … 費用だけで見ない。習熟・障害対応・移行の方が高い
- 習熟コストをゼロとみなす … 「深夜に直せる人」の有無まで見る
- 性能問題を製品変更だけで解こうとする … まずクエリ・インデックス・設計
- 既存資産を無視して新規エンジンに寄せる … 移行理由が先
現場でありがちなパターン
- .NET 新規 → SQL Server または Azure SQL。チームが PostgreSQL に慣れているならそちらも十分あり
- AWS 上の Web API → PostgreSQL or MySQL on RDS / Aurora
- 既存 SQL Server / Oracle 大量 → 原則継続。移行は「なぜ移すか」が先
- レポート・分析が重い → 本番 OLTP と同じ箱に押し込めず、倉庫・レプリカを分ける検討
チェックリスト
- チームが習熟しやすいか？／経験者を確保しやすいか？
- 既存 DB / ライセンス / クラウド指定はあるか？
- 費用（ライセンス・クラウド・人件費・移行）を見積もったか？
- マネージドにするか？ RPO / RTO は？
- アプリ（EF Core / Dapper 等）との相性は確認したか？
- Oracle 新規や SQLite 本番共有など、比較的選ばれにくい選択をしていないか？理由は説明できるか？
まとめ
- 新規でよく並ぶのは SQL Server / PostgreSQL / MySQL。Oracle 新規や SQLite 本番共有は比較的選ばれにくい
- コストは 費用（ライセンスは SQL Server / Oracle が高くなりやすい） と 習熟。ライセンスが安くても習熟が足りなければ高くつく
- 選定は要件が先。流行とエンジン変更は後
関連記事