変更要約: 初版（主題S1・S1.1〜S1.2）
1.1OSS-DBの一般的特徴
PostgreSQL の機能全般を俯瞰し、OSS（オープンソースソフトウェア）と PostgreSQL ライセンス の性質、開発を支えるコミュニティの活動・参加方法を押さえます。さらに メジャーバージョン／マイナーバージョン の意味の違い、約1年ごとのリリースサイクル、サポートポリシー（5年間の更新提供）、コミュニティへのバグ報告の流れを学びます。
OSS-DB Silver の最初の一歩は、PostgreSQL という製品そのものを「ソフトウェアとして」「プロジェクトとして」正しく理解することです。SQL の書き方や運用コマンドを覚える前に、なぜこの OSS が長期的に安定して使えるのか——ライセンス・コミュニティ・バージョン管理という土台を押さえておくと、後続の章（運用管理・SQL）の理解が一段と早くなります。
1.1.1PostgreSQLの機能全般とライセンス
- PostgreSQL＝オブジェクトリレーショナルデータベース管理システム（ORDBMS）。標準 SQL への準拠度が高く、JSON/JSONB・配列・拡張型といった高度なデータ型、トリガー・ビュー・ストアドプロシージャなど本格的な RDBMS 機能をひととおり備える。
- 主な機能：ACID に準拠したトランザクション（原子性・一貫性・分離性・永続性）で信頼性を担保し、MVCC（多版型同時実行制御）により読み取りが書き込みをブロックしない高い同時実行性を実現する。加えて標準SQLへの準拠度が高く、拡張機能で後から機能を足せる。
- OSS（オープンソースソフトウェア）＝ソースコードが公開され、誰でも利用・改変・再配布できるソフトウェア。PostgreSQL ライセンスはこの性質を持つ寛容型（permissive）ライセンスで、商用利用や改変後のクローズドソース化にも大きな制限を課さない。
- 寛容型ライセンスの実務上の意味＝クラウドベンダーが PostgreSQL 互換のマネージドサービスを独自に提供したり、企業が改変版を製品に組み込んだりする自由度が高い。この自由度の高さが PostgreSQL 系エコシステムの多様さにつながっている。
1.1.2コミュニティとバージョニング・サポート
- PostgreSQL のコミュニティは、単一企業ではなく世界中の開発者・企業が参加する分散型のグローバルコミュニティによって開発が進められる。メーリングリストでの議論、パッチの投稿・レビュー、カンファレンスでの発表などが主な活動。
- コミュニティへの参加方法は、メーリングリストの購読、不具合や改善要望の報告、ドキュメントの翻訳、パッチの提供など多様な入口がある。特別な承認プロセスなしに誰でも議論に参加できる開放性が特徴。
- メジャーバージョン＝機能追加や仕様変更を伴う大きな更新（例：12→13→14）。マイナーバージョン＝同一メジャーバージョン内でのバグ修正・セキュリティ修正のみを含む更新（例：14.1→14.2）で、原則として機能追加は行わない。
- リリースサイクル＝メジャーバージョンは概ね年1回のペースで新規リリースされる。サポートポリシー＝各メジャーバージョンはリリース後おおむね5年間、マイナーバージョンの更新（不具合・セキュリティ修正）が提供される。
- バグ報告＝コミュニティが提供するバグトラッカー（フォーム経由でメーリングリストへ）に、再現手順・バージョン・環境情報を添えて報告する。ユーザーからの正確な報告が品質向上の重要な入力となる。
「メジャー＝機能追加あり／マイナー＝修正のみ」「リリースサイクルは年1回」「サポートは約5年」 という3点セットの数値・定義が最頻出です。PostgreSQL ライセンスが寛容型（GPL のような強い制限を課さない）であること、コミュニティが特定企業に閉じていない分散型である点も定番の出題ポイントです。
あるチームが「本番環境の PostgreSQL をいつ・どう更新するか」を検討する場面を想像してみましょう。まず現在稼働中のバージョンが 12.10 だとすると、これはメジャーバージョン12・マイナーバージョン10を意味します。セキュリティ修正だけを取り込みたいなら、次のマイナーリリース（例：12.11）へ更新すれば十分で、アプリケーションの互換性への影響はほぼありません。一方、メジャーバージョン12から13・14へアップグレードする場合は、機能追加や内部仕様の変更を伴うため、リリースノートを確認し、事前に検証環境でアプリケーションの動作確認を行う必要があります。チームはサポートポリシーも踏まえて計画を立てます。稼働中のメジャーバージョンがリリースから5年に近づいているなら、サポート終了（EOL）前に次のメジャーバージョンへの移行を計画しなければなりません。もし運用中に想定外の挙動（バグ）を発見したら、まず既知の不具合でないかコミュニティの情報を確認し、未報告であれば再現手順・バージョン・OS 環境を整理してバグ報告として提出します。このように、ライセンスの自由度・コミュニティの開放性・明確なバージョニングとサポート期間が、企業が安心して長期運用を計画できる基盤になっています。
| 観点 | メジャーバージョン | マイナーバージョン |
|---|---|---|
| 例 | 12 → 13 → 14 | 14.1 → 14.2 |
| 内容 | 新機能・仕様変更を含む | バグ修正・セキュリティ修正のみ |
| リリース頻度 | 概ね年1回 | 随時（必要に応じ複数回） |
| 互換性への影響 | 事前検証が必要 | ほぼ影響なし |
ひっかけ： 「PostgreSQL ライセンスは GPL と同じ強いコピーレフト（改変版も必ず公開義務）である」は誤りです。PostgreSQL ライセンスは寛容型で、改変後にソースを公開する義務を課しません。また「マイナーバージョンアップでも新機能が追加されることがある」も誤り＝マイナーバージョンは修正のみが原則で、新機能はメジャーバージョンでのみ導入されます。
1.1.3この節のまとめ
- PostgreSQL＝ORDBMS（JSON/JSONB等の高度な型・トリガー・ビュー等を備える）。ライセンスは寛容型で改変版の公開義務なし
- コミュニティは分散型（単一企業に非依存）。誰でも参加可能＝メーリングリスト・パッチ・バグ報告など
- メジャー＝機能追加あり／マイナー＝修正のみ。リリースサイクルは年1回・サポートは約5年
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 本番環境で稼働している PostgreSQL 14.2 を、セキュリティ修正のみを取り込んで更新したい。事前のアプリケーション互換性検証がほぼ不要な更新はどれ？
Q2. PostgreSQL のライセンスに関する説明として正しいのはどれ？
Q3. 運用中の PostgreSQL で未知の不具合と思われる挙動を発見した。コミュニティに対して行うべき最も適切な対応はどれ？