PostgreSQL (ポストグレス キューエル[ ※ 1] )は、拡張性とSQL準拠を強調するフリーでオープンソース の関係データベース管理システム (RDBMS)である。Postgresとしても知られている。もともとは、カリフォルニア大学バークレー校 で開発されたIngres データベースの後継としてその起源を根拠としたPOSTGRESという名前であった。1996年に、プロジェクトはSQLのサポートを反映してPostgreSQLに改名された。2007年の検討の結果、開発チームはPostgreSQLという名前とPostgresという別名を維持することを決定した。
PostgreSQLは、原子性、整合性、独立性、耐久性 (ACID)プロパティを持つトランザクション、自動更新可能なビュー 、マテリアライズドビュー 、トリガ 、外部キー 、ストアドプロシージャ を特徴としている。単一マシンからデータウェアハウス や多数の同時使用ユーザを持つWebサービス まで、さまざまなワークロードを扱えるように設計されている。かつてのMac OS X Lion ServerからmacOS Server 5.7 までデフォルトデータベースであった。macOS 、Linux 、FreeBSD 、OpenBSD 、Windows でも利用可能である。
概要
PostgreSQLはIllustra や、Illustraを買収しその技術を採りいれたInformix とともにオブジェクト関係データベース管理システムを実装してきた[ 4] 。問い合わせ言語には SQL を用いており、SQL92, 99 の大部分と、2003 , 2008 の一部をサポートしている[ ※ 2] 。
市場シェア
Stack Overflow の2023年[ 5] や2024年[ 6] の調査では2023年にMySQLを超えて、世界で最も使われているデータベースだった。
DB-Engines.comによるマーケットシェア調査では、2018年2月当時、Oracle Database、MySQL、Microsoft SQL Server に続いて4位であり[ 7] 、MySQL とのシェアの差は年々縮まる傾向にあった[ 8] 。
2012年7月当時は、クラウドサービスプロバイダの Jelastic によると、オープンソースDBの中でのPostgreSQLの世界シェアは Jelastic のユーザー内では14%程度であった(MySQL 系 70%(MySQL 56%、MariaDB 14%)、MongoDB 15%)[ 9] 。日本の Jelastic のユーザー内では8%であり(MySQL系 66%(MySQL 50%、MariaDB 16%))、世界的なシェアとは状況が異なる[ 9] 。
プラットフォーム
特徴
関数
関数(ストアドファンクション )によりサーバで実行される処理のまとまりを定義できる。PostgreSQL は行 を返却する関数を定義することができる。関数の出力は複数の行であり、クエリの中でテーブル と同様に扱うことができる。実行するユーザまたは定義したユーザのどちらの権限で実行されるかを指定して関数を定義できる。
関数の定義には SQL の他、分岐やループをサポートする下記の言語で実装することが可能である。言語によっては関数をデータベーストリガ として実行することもできる。
外部のプロジェクトとして対応している言語
[ 14]
インデックス
PostgreSQL は組み込みで以下のインデックス をサポートしている[ 15] 。デフォルトはB+木。また、ユーザ定義インデックスを追加することもできる。
PostgreSQL のインデックスには以下の特徴がある。
必要に応じて逆順でスキャンできる。逆順スキャン用のインデックスを別に定義する必要は無い。
式インデックス (関数インデックス) を定義できる。複数の列の値を引数に取る関数の結果をインデックス化する。
部分インデックス (条件付きインデックス) を定義できる。条件を指定し、条件に適合する行のみをインデックス化することで、インデックスのサイズを縮小できる。
クエリオプティマイザ (planner) は複数のインデックスを同時に使用するクエリ実行計画 を作成できる。複数のインデックスの結果をメモリ上のビットマップとして併せ、そのビットマップに対応する行をテーブルから取得する。
トリガ
データベーストリガ は SQL データ操作言語 (SQL DML) の文 (INSERT , UPDATE / UPDATE OF, DELETE , TRUNCATE ) を実行した際に呼び出される。利用例として、INSERT 文で挿入される値が妥当かの検証がある。トリガが実行される条件は WHEN 句で与えることができる。
トリガはテーブルに対してのみ定義できる。ビューに対するトリガが必要な場合には、代わりにルール を使用する。複数のトリガが定義されている場合、アルファベット順に実行される。
トリガで実行される処理は関数として定義する。トリガ用の関数の定義には SQL 関数は使用できないが、PL/pgSQL やその他の多くの関数用言語を使うことができる。
ルール
ルールにより SQL の内部表現である「クエリ木」を書き換えることができる。一般的なルールの用途は更新可能ビューを実現することであり、標準 SQL で規定される "INSTEAD OF" トリガ の代わりに用いられる。
データ型
多くのデータ型 が利用できる[ 20] 。
数値型:整数、浮動小数点数、任意の精度を持つ数値、連番
通貨型
文字列:固定長、可変長
可変長バイト列
日時、日付、時刻、時間差分 (タイムゾーン の有無を指定可能)
ブーリアン型
列挙型(8.3以降)
幾何型:点、直線、線分、矩形、閉経路、開経路、多角形、円
ネットワークアドレス:IPv4 / IPv6 アドレス, MAC アドレス
ビット列
テキスト検索に関する型
UUID 型
XML 型
JSON 型:テキスト形式、バイナリ形式
配列 型
複合型
範囲型
可変長文字列と可変長バイト列には最大で 1GB を格納できる。一定のサイズを上回るデータ値は TOAST と呼ばれる機能により自動的に圧縮され別領域に配置される。そのため、ページサイズ (通常8KB) を上回るサイズの行であっても保存できる。
さらに、ユーザがデータ型を追加することもでき、それに対してインデックスを作成することもできる。
利用例として、GIS 用の型を GiST インデックスで検索可能な PostGIS プロジェクトがある。
ユーザ定義オブジェクト
ユーザはほとんどのデータベース・オブジェクトを追加できる。
データ型 (TYPE) と データの定義域 (DOMAIN)
関数 (FUNCTION) と集約 (AGGREGATE)
演算子 (OPERATOR)
型変換 (CAST)
文字コード 変換 (CONVERSION)
手続き言語 (LANGUAGE)
全文検索 の設定 (TEXT SEARCH CONFIGURATION)
インデックス・アクセス・メソッド
PostgreSQLが規定する上限
データベースの大きさの上限はない。テーブルのバイト数の最大は32Tbyteである。
テーブルの列は1600まで可能だが、運用上の上限はデータ型に依存する。
バキューム
バキューム (VACUUM) とは、追記型アーキテクチャ における不要領域を回収し、再利用またはOSに返却する処理である。なお、バージョン8.3からはHeap-Only Tuples (HOT) が採用され、インデックスの変更を伴わない更新については、削除された行を直ちに再利用することが可能となり、バキュームの必要な頻度は下がった。
PostgreSQLは、MVCC の実現のため、追記型のアーキテクチャ を採用している。データを削除する際は実際のレコードは削除せず、該当行に削除マークを付けるのみである。更新の際も内部的には削除と挿入を同時に行っている。そのため、更新・削除が繰り返されるテーブルにおいては、たとえ理論的な行数が変わらなくとも、更新・運用を重ねるごとに物理的なファイルサイズが増加する。肥大化によるパフォーマンスの劣化を回避するため、次節に述べるバキューム作業を定期的に行う必要がある。
各バージョンによって以下の差異がある。
7.1 以前
データベースファイル内の未使用領域を解放しOSに返却する処理のみをサポートする。このVACUUMでは、処理中のテーブルに対して排他ロックが獲得されるため、VACUUMの間は対象テーブルへのアクセスがブロックされる。システムの規模やテーブルの行数にもよるが、本バージョンにおいてシステムの停止を伴わない運用は困難であった。
7.2
以前の動作を FULL 方式 (VACUUM FULL) とし、新たにコンカレント方式 (VACUUM) が実装された。現在、単にバキュームと言った場合、後者のコンカレントバキュームを指す。コンカレントバキュームでは、テーブルの排他ロックを伴わずに不要領域の回収を行う。不要領域に対して再利用可能フラグを付けるのみの処理となるため、コンカレントバキュームを行っても基本的にデータベースの物理的なサイズは縮小しない。しかし、以降の更新・挿入において、このとき回収した領域が優先的に使用され、更新・削除によるファイルサイズの肥大を防止できる。
7.3
インデックスもコンカレントバキュームの対象になり、肥大化から回復させるための定期的にインデックスを再編成 (REINDEX) する必要が無くなった。これによりデータベース・オブジェクトの排他ロックを要するメンテナンスが不要になり、無停止での運用が可能になった。
7.4
自動的にバキュームを行う contrib/pg_autovacuum モジュールが提供された。autovacuum はシステムを監視し、INSERT/UPDATE/DELETE の回数などの統計情報を利用して、適切なタイミングで適切なテーブルのみに対してバキュームを行う。このため、高度な知識を要すことなく、不要領域の増加を十分に抑えることが可能となった。なお、自動バキューム処理の際に参照される統計情報の記録はデフォルトでオフとなっているため、本機能を利用する際は統計情報の記録オプションもオンにする必要がある。
8.0
バキュームは多くのI/Oが必要なため、負荷の高い処理である。バキューム実行中のシステムの全体の性能悪化を防ぐため、バキュームを行う速度を制限する機能が追加された。ただし、バキューム自体の処理時間はその分多く要する。
8.1
contribより提供されていた自動バキューム (autovacuum) 機能が本体に統合された。不要領域の監視が効率化され、コマンドで発行した VACUUM との連携が可能になった。
8.2
トランザクションIDの周回がテーブル単位で管理されるようになり、定期的にデータベース単位でバキュームを行う必要が無くなった。テーブル単位のバキュームのみが必要である。また複数のバキュームを並列して実行した際の回収効率が向上した。
8.3
自動バキューム機能が標準で有効とされ、複数のテーブルに並列してバキュームを行うようになった。加えて Heap-Only Tuples の採用により、バキューム自体の必要性が低減した。
8.4
Visibility Map で処理が必要なページを追跡するようになり、バキュームが高速化された。また空き領域のあるページを管理する Free Space Map のメモリ管理が自動化された。
9.0
VACUUM FULL が CLUSTER と類似の処理に変更され、高速化された。
パーティショニング
PostgreSQL 8.1 より、パーティショニングを組み込みでサポートしている。バージョンが上がる度に機能が追加されている。
テーブル・パーティショニング は継承 を用いて実現する。これは、Oracle Database 7 のパーティション・ビューに近い実装である。
テーブルを作成する際、他テーブルを「親」テーブルとして指定し、継承関係を定義できる。
「子」テーブルに挿入された行は、親テーブルを参照した際にも取得される。親テーブルに対する列の追加やCHECK制約 の定義は自動的に子テーブルにも反映されるが、外部キー や一意性制約 は継承をサポートしていない。
パーティショニングされたテーブルへは親テーブルを通してアクセスする。SELECT , UPDATE , DELETE 文は子テーブルを含むよう展開されるが、クエリの条件が CHECK 制約に適合しない子テーブルは設定により自動的に除外することもできるため効率よく処理できる。
INSERT については、バージョン10以降は宣言的テーブルパーティショニングにより子テーブルに振り分けることが出来る[ 21] 。バージョン9.6までは、子テーブルを直接指定するか、親テーブルにトリガを作成することで挿入先を指示して振り分けることが出来る。
レプリケーション
PostgreSQL 9.0 より、ストリーミングレプリケーション を組み込みでサポートしている[ 22] 。トランザクションログ を転送し、全てのデータベース・ファイルの変更をコミット後に他のサーバへ非同期に転送する。単一マスタと複数スレーブを構成でき、スレーブは参照の問い合わせを受け付ける。参照処理を複数のノードで負荷分散するスケールアウト が可能である。
PostgreSQL 10 より、ロジカルレプリケーションを組み込みでサポートしている[ 23] 。データベース全体ではなく、指定した部分だけをレプリケーションできる。
全文検索
LIKE 述語と正規表現 による文字列検索のほか、全文検索 の機能を持つ。バージョン 8.3 以降は組み込みで、それ以前のバージョンでは contrib/tsearch2 として提供されている。この全文検索では文字列から単語を抽出し、転置テーブル (GIN ) または単語空間を多次元木 (GiST ) とするインデックスを作成できる。SQL/MM の全文検索とは異なり、「@@」演算子を使用する独自の文法で検索を行う。
SELECT * FROM テーブル WHERE to_tsvector ( 文字列カラム ) @@ to_tsquery ( '検索クエリ' )
標準では日本語の文字列から単語を抽出するパーサを持たないが、外部拡張である textsearch-ja を使用することで形態素解析 による検索が可能となる。
また、標準の全文検索以外にも、PGroonga (Groonga を使用), Ludia , textsearch_senna (Senna を使用), pgestraier (Hyper Estraier ), pgRast (Rast ) などが外部拡張として存在する。
UPSERT機能
PostgreSQL 9.5 より、データの新規挿入または更新を行う「UPSERT」機能が実装された[ 24] 。「UPSERT」機能とは、データの新規挿入(INSERT)ができれば挿入を行い、新規挿入ができなければ更新(UPDATE)を行うもの。「ON CONFLICT」句を指定すると、データ変更の衝突を適切に処理できるという。
基本的機能
その他の特徴
オンラインオフラインバックアップ
バックアップには主に3つの方法があり、SQLダンプ、ファイルシステムレベルバックアップ、連続アーカイブである。それぞれに長所・短所がある。SQLダンプではpg_dumpのようなクライアントアプリケーションでバックアップをとり、リモートホストからのバックアップが可能であるがデータベース全体のバックアップをとる場合にはほぼ常にスーパーユーザー権限が必要である。ファイルシステムレベルバックアップでは、bashコマンドでデータファイルのバックアップをとる。この場合はオンラインバックアップやテーブル個別のバックアップは出来ない。連続アーカイブはWALを利用するものであり、アドミニストレータにとって複雑であるが、バックアップでの内部不整合がlog replayで解決されることやWALファイルをアーカイブするだけで連続バックアップできる利点もある。ただこの方法ではデータベースクラスタ全体のバックアップとなるため要求されるストレージは大である[ 25] 。
性能
CPU スケーラビリティ
バージョン 8.1 以降 CPU スケーラビリティ は大幅に改善された。
以降、改善を積み重ね、中規模のハードウェアであればスケーラビリティを十分に確保できるRDBMSとなっている。
7.4 以前
スケーラビリティはページ置換アルゴリズム として採用されていた LRU により抑制されていた。ページを参照するたびにバッファ・プール全体を排他ロックしていたため、スケーラビリティは低かった。SMP 構成で 4CPU 程度が限界だった。
8.0
LRU に代わり ARC が採用された(ただし、特許侵害の回避のため途中で 2Q に変更された[ 26] )。ARC によりキャッシュヒット率は向上したものの、排他制御にオーバーヘッドが生じた。また、サブトランザクションをサポートするため追加された排他制御も新たなロック競合を生んだ。スケーラビリティは以前のバージョンと比較してむしろ低下しており、2CPU 程度で頭打ちになった。
8.1
ページ置換アルゴリズムはクロック に変更され、スケーラビリティが大幅に向上した。ページの参照には共有ロックのみが必要であるため並行してアクセスが可能になった。8コア程度が上限となった。[ 27] [ 28]
8.2
ページを管理するハッシュテーブルのロックが16個に分割され、共有ロックの実装に使用されるスピンロック へのアクセスが分散された。他にスピンロックの実装やサブトランザクションの排他制御が改良され、16コアまでのスケーラビリティが確認されている。[ 29] [ 30]
9.2
EnterpriseDB の Robert Haas が Linux カーネル 3.2 および PostgreSQL 9.2 の改善により、64コア(8コア×8CPU)のマシン上でCPUスケールすることを確認した[ 29] 。
9.5
LWLock (Lightweight lock) において、一部、スピンロックからアトミック命令に切り替え[ 31] 、また、共有バッファのマッピングのハッシュテーブルのパーティション数を16から128に増やす[ 32] などの改善により、並列度が32〜64あたりでのパフォーマンスを改善した[ 33] [ 34] 。
更新処理
過去のバージョンの PostgreSQL は他の関係データベース管理システム (RDBMS) と比較して更新処理が遅いと言われていた。追記型アーキテクチャが採用されており、更新処理は削除と挿入の組み合わせとして実現されていた。特に挿入の際にインデックスのキーを追加する必要がある点で性能差が生じていた。
しかし、バージョン 8.3 にて Heap-Only Tuples (HOT) と呼ばれる機能が採用され、インデックスのキーとなっている列の値に変更が無い場合にはインデックスの更新を回避できるようになった。HOT により約2倍のスループット向上が確認されている。[ 35]
ベンチマーク
業界標準の規格に則ったベンチマーク結果として 2007年8月の サン・マイクロシステムズ (Sun) による報告がある。以下のハードウェアを使用し、813.73 SPECjAppServer2004 JOPS@Standard であった。[ 36]
周辺ツール
管理ツール
PostgreSQL専用もしくは各種データベース汎用のデータベース接続クライアント を利用して管理できる。
psql
psql は PostgreSQL 付属のコマンドライン・プログラムである。SQL を直接入力またはファイルから読み込んで実行するほか、スキーマ情報の表示などのメタコマンドを持つ。また、SQL 構文やテーブル名などをタブキーにより入力補完できる。
pgAdmin
pgAdmin [ ※ 8] は GUI の管理インタフェースである。PostgreSQL License で配布される オープンソースソフトウェア (OSS) である。多くのプラットフォームで動作し、日本語を含む多くの言語が利用できる。また、専用の SQL エディタは psql と同様の入力補完機能を持つ。Microsoft SQL Server Management Studio と似たインタフェースでデータベースを操作できる。
phpPgAdmin
phpPgAdmin [ ※ 9] はウェブベースの管理ツールである。PHP で作られており GPL で配布されている。名称はphpMyAdmin と似ているが、製品同士の関連性は無く、操作性はかなり異なる。
その他
レプリケーション・アドオン
PostgreSQL はバージョン 9.0 よりレプリケーション を標準でサポートするが、サードパーティー 製のオプション・ソフトウェアも利用できる。
接続インタフェース
PostgreSQL はクライアントサーバモデル であり、データベースへの接続は主に TCP/IP ポート番号 5432 を用いて通信を行う。通信プロトコル は「フロントエンド/バックエンドプロトコル[ 37] 」として公開されている。
歴史
マイケル・ストーンブレーカー は、自分が開発を主導した関係データベース管理システム (RDBMS) であるIngres の商業化事業を一段落させると、カリフォルニア大学バークリー校 (UCB) に戻り、同校で新たなプロジェクトを開始した。プロジェクトの名称は Postgres と名づけられた。このプロジェクト名称は、Ingres の後継を意味する Post-Ingres に由来している。Postgresプロジェクトは、関係モデル を使ったこれまでの既存のデータベース管理システム の限界に対処することを目的として、開始された。最も重要な課題は、これまでのDBMSではユーザが自分で新たな定義域 (ドメイン、型) を既存の単純な定義域をもとにして定義できない点であった。Postgresでは型 (定義域) を完全にサポートするために必要な最小限の機能だけを導入した。Postgres ではデータベースが関係を「理解」すると言われ、「規則」に従って自然な方法で関連する関係 (リレーション 、表、テーブル ) から情報を得ることができた。ユーザ自身が型を定義する機能に加えて、関連を完全に記述できる機能も備えていた。プロジェクトは他にも、追記型メディア (光ディスクなど) への対応、大容量記憶装置への対応、推論、オブジェクト指向型データモデル などを、取り入れた。実装においては、データベース とアプリケーションソフトウェア の間の新たなインタフェース を実験的に導入した。
プロジェクトチームは、1986年からPostgresシステムの基盤を説明した多数の論文を公表した。1988年、Postgres のプロトタイプ バージョンを発表した。1989年6月、数名のユーザに対してPostgresバージョン1を公開した[ 2] 。1990年6月、ルールシステム (RULE) を実装し直したバージョン2を公開した[ 2] 。1991年、バージョン3を公開した[ 2] 。バージョン3では、ルールシステムが再度実装し直され、複数の記憶装置を管理する機構が追加され、クエリエンジンが改良された。1993年には、非常に多くのユーザが、プロジェクトに対して、サポートと追加機能を要望して、圧倒させるほどの状態となっていた。1993年、主として雑然とした部分をきれいにしたことを内容とするバージョン4.2が公開された。バージョン4.2が公開された後、Postgres プロジェクトは終了した[ 2] 。Postgres は広く使われたが、保守 はユーザに任されていた。
マイケル・ストーンブレーカーと Paula Hawthorn は、Postgresを商業化するために、Illustra Information Technologies 社を創業して、Illustra の製品名で開発・販売した。その技術は IBM Informix Dynamic Server (IDS) に導入されている。
一方、オープンソース の世界のソフトウェア開発者 たちは、Postgres のコピーを入手してシステムのさらなる開発を進めることができた。なぜならカリフォルニア大学バークリー校 (UCB) は、Postgres をオープンソースライセンス であるBSDライセンス のもとで公開していたからである。1994年に、カリフォルニア大学バークリー校 (UCB) の大学院生であった Andrew Yu と Jolly Chen は、システムの問い合わせ言語 のインタプリタ を、Ingres を基にした QUEL のインタプリタから、SQL のインタプリタに置き換える作業を行った。SQLインタプリタを備えたこのシステムは、Postgres95 と呼ばれた。Postgres95 のソースコード は、ワールドワイドウェブ に公開された。
1996年7月に Hub.Org Networking Services の Marc Fournier は、大学外の組織としては最初に、開発用サーバをオープンソースソフトウェア開発のために活動する人々に提供した。Postgres95プロジェクトは、Bruce Momjian と Vadim B. Mikheev とともに、カリフォルニア大学バークリー校 (UCB) に由来するソースコード を堅牢にする作業を始めた。1996年8月1日に、Postgres95の最初のオープンソースのバージョンが公開された。
1996年に Postgres95 プロジェクトは、プロジェクトの名称を、SQL のサポートをしているという意味をこめて PostgreSQL に変更した[ 2] 。1997年1月に PostgreSQL プロジェクトとしての最初のバージョンである、PostgreSQL バージョン 6.0 が公開された。このときから、インターネット を通じて世界中のデータベース開発者のグループがPostgreSQLの開発に参加し、共同作業によるプロジェクトをうまく調整する体制ができあがった。
1999年7月23日、日本PostgreSQLユーザ会が設立し、任意団体として活動を開始した[ 39] 。
Postgres は Illustra により商業化されていたが、Illustra は Informix に買収され、Informix は 2001年に IBM に買収された[ 2] 。2001年以降には PostgreSQL を商用サポートする会社が現れた。
2006年2月1日、日本PostgreSQLユーザ会は NPO として再編成された[ 39] 。
2011年7月、オープンソースデータベース技術者認定試験 (OSS-DB Exam)において基準のRDBMSとして採用された。
バージョン履歴
1986年 - カリフォルニア大学バークレー校 (UCB) でマイケル・ストーンブレーカー がPOSTGRESプロジェクトを発足[ 2] 。
1987年 - プロトタイプ が完成、翌年のACM-SIGMOD コンファレンスで紹介される[ 2] 。
1989年6月 - POSTGRES 1 を数名の外部ユーザーにリリース[ 2] 。
1990年6月 - POSTGRES 2 のリリース。前バージョンの批評をもとにルールシステムが再設計された[ 2] 。
1991年 - POSTGRES 3 のリリース。複数ストレージの管理機構追加等[ 2] 。
1993年 - POSTGRES 4.2 をもってカリフォルニア大学バークレー校におけるPOSTGRESプロジェクトが終了[ 2] 。
Postgres95
バージョン
リリース日
追加機能
0.01
000000001995-05-01-0000 1995年5月1日
POSTGRESのソースコードを元にした Postgres95 のリリース
1.0
000000001995-09-05-0000 1995年9月5日
SQL LIKE構文などを実装した Postgres95 の正式リリース
PostgreSQL
メジャーバージョン
リリース日
最新マイナー版
最新版リリース日
サポート期限
追加機能
6.0
000000001997-01-29-0000 1997年1月29日
—
—
—
PostgreSQL と名称を変え、POSTGRESプロジェクトの連番に戻された
6.1
000000001997-06-08-0000 1997年6月8日
サポート終了: 6.1.1
000000001997-07-22-0000 1997年7月22日
—
6.2
000000001997-10-02-0000 1997年10月2日
サポート終了: 6.2.1
000000001997-10-17-0000 1997年10月17日
—
6.3
000000001998-03-01-0000 1998年3月1日
サポート終了: 6.3.2
000000001998-04-07-0000 1998年4月7日
000000002003-03-01-0000 2003年3月1日
副問い合わせ , PL/Tcl
6.4
000000001998-10-30-0000 1998年10月30日
サポート終了: 6.4.2
000000001998-12-20-0000 1998年12月20日
000000002003-10-30-0000 2003年10月30日
PL/pgSQL , マルチバイト文字列サポート, ビュー
6.5
000000001999-06-09-0000 1999年6月9日
サポート終了: 6.5.3
000000001999-10-13-0000 1999年10月13日
000000002004-06-09-0000 2004年6月9日
MVCC , 一時表, CASE, INTERSECT, EXCEPT
7.0
000000002000-05-08-0000 2000年5月8日
サポート終了: 7.0.3
000000002000-11-11-0000 2000年11月11日
000000002004-05-08-0000 2004年5月8日
外部キー 制約
7.1
000000002001-04-13-0000 2001年4月13日
サポート終了: 7.1.3
000000002001-08-15-0000 2001年8月15日
000000002006-04-13-0000 2006年4月13日
WAL , TOAST, OUTER JOIN
7.2
000000002002-02-04-0000 2002年2月4日
サポート終了: 7.2.8
000000002005-05-09-0000 2005年5月9日
000000002007-02-04-0000 2007年2月4日
コンカレントVACUUM, PL/Python
7.3
000000002002-11-27-0000 2002年11月27日
サポート終了: 7.3.21
000000002008-01-07-0000 2008年1月7日
000000002007-11-27-0000 2007年11月27日
スキーマ , ドメイン , PREPARE
7.4
000000002003-11-17-0000 2003年11月17日
サポート終了: 7.4.30
000000002010-10-04-0000 2010年10月4日
000000002010-10-01-0000 2010年10月1日
IPv6 , information_schema
8.0
000000002005-01-19-0000 2005年1月19日
サポート終了: 8.0.26
000000002010-10-04-0000 2010年10月4日
000000002010-10-01-0000 2010年10月1日
Microsoft Windows 対応, SAVEPOINT , PITR, 表領域 [ 40]
8.1
000000002005-11-08-0000 2005年11月8日
サポート終了: 8.1.23
000000002010-12-16-0000 2010年12月16日
000000002010-11-08-0000 2010年11月8日
2相コミット , ROLE , 行共有ロック, テーブル・パーティショニング [ 41]
8.2
000000002006-12-05-0000 2006年12月5日
サポート終了: 8.2.23
000000002011-12-05-0000 2011年12月5日
000000002011-12-05-0000 2011年12月5日
ウォームスタンバイ, GIN [ 42]
8.3
000000002008-02-04-0000 2008年2月4日
サポート終了: 8.3.23
000000002013-02-07-0000 2013年2月7日
000000002013-02-07-0000 2013年2月7日
更新処理性能の向上, XML データ型, 全文検索 , JIS X 0213 , ENUM型 , UUID 型 [ 43]
8.4
000000002009-07-01-0000 2009年7月1日
サポート終了: 8.4.22
000000002014-07-24-0000 2014年7月24日
000000002014-07-24-0000 2014年7月24日
再帰クエリ , ウィンドウ関数 , 列単位のアクセス制御 , SQLと関数の性能解析 機能 [ 44]
9.0
000000002010-09-20-0000 2010年9月20日
サポート終了: 9.0.23
000000002015-10-08-0000 2015年10月8日
000000002015-10-08-0000 2015年10月8日
レプリケーション , 一括権限変更, 匿名プロシージャ, 64bit Windows サポート, 移動平均 , 列/条件トリガ , 一意性制約 の遅延, 排他制約 [ 45]
9.1
000000002011-09-12-0000 2011年9月12日
サポート終了: 9.1.24
000000002016-10-27-0000 2016年10月27日
000000002016-10-27-0000 2016年10月27日
同期レプリケーション, 外部テーブル, パッケージ管理, UNLOGGEDテーブル, 更新可能なWITH句, 近傍検索, SELinux 権限制御[ 46]
9.2
000000002012-09-10-0000 2012年9月10日
サポート終了: 9.2.24
000000002017-11-09-0000 2017年11月9日
000000002017-11-09-0000 2017年11月9日
インデックスオンリースキャン, カスケードレプリケーション, JSON型, 範囲型[ 47]
9.3
000000002013-09-09-0000 2013年9月9日
サポート終了: 9.3.25
000000002018-11-08-0000 2018年11月8日
000000002018-11-08-0000 2018年11月8日
マテリアライズドビュー , 外部テーブルへの書き出し, イベントトリガ, データページ・チェックサム , LATERAL句[ 48]
9.4
000000002014-12-18-0000 2014年12月18日
サポート終了: 9.4.26
000000002019-11-14-0000 2019年11月14日
000000002020-02-13-0000 2020年2月13日
JSONB型, SQLからのサーバー設定の変更(ALTER SYSTEM), レプリケーションスロット[ 49]
9.5
000000002016-01-07-0000 2016年1月7日
サポート終了: 9.5.25
000000002021-02-11-0000 2021年2月11日
000000002021-02-11-0000 2021年2月11日
UPSERT機能, ALTER TABLE tablename ENABLE ROW LEVEL SECURITYコマンド, ブロックレンジインデックス(BRIN)[ 50]
9.6
000000002016-09-29-0000 2016年9月29日
サポート終了: 9.6.24
000000002021-11-11-0000 2021年11月11日
000000002021-11-11-0000 2021年11月11日
同期レプリケーション機能の強化(「remote_apply」モード), PostgreSQL間のデータ連携ドライバー(「postgres_fdw」)の強化(リモート下にあるサーバーにおいても実行可能となる)[ 51]
10
000000002017-10-05-0000 2017年10月5日
サポート終了: 10.23
000000002022-11-10-0000 2022年11月10日
000000002022-11-10-0000 2022年11月10日
ロジカルレプリケーション, 宣言的テーブルパーティショニング(Declarative Table Partitioning)[ 52]
11
000000002018-10-18-0000 2018年10月18日
サポート終了: 11.22
000000002023-11-09-0000 2023年11月9日
000000002023-11-09-0000 2023年11月9日
ハッシュキーによるデータのパティショニング, (デフォルトでは搭載していないがLLVM をビルドすることで)クエリの一部の処理時間を短縮するJITコンパイラ のサポート[ 53]
12
000000002019-10-03-0000 2019年10月3日
サポート中: 12.19
000000002024-05-09-0000 2024年5月9日
000000002024-11-14-0000 2024年11月14日
クエリパフォーマンスとスペース使用率の改善, SQL/JSONパス式のサポート, 生成列, 国際化と認証の改善, 新しいプラガブルテーブルストレージインターフェイス[ 54]
13
000000002020-09-24-0000 2020年9月24日
サポート中: 13.15
000000002024-05-09-0000 2024年5月9日
000000002025-11-13-0000 2025年11月13日
Bツリーインデックス項目の重複除去による省スペース化と性能向上, 集約やパーティションテーブルを使う問い合わせの性能改善, 拡張統計情報を使ったときのより良い問い合わせの計画作成, 並列化されたインデックスのバキューム, インクリメンタルソート[ 55] [ 56]
14
000000002021-09-30-0000 2021年9月30日
サポート中: 14.12
000000002024-05-09-0000 2024年5月9日
000000002026-11-12-0000 2026年11月12日
共通テーブル式にSQL標準のSEARCHとCYCLE句を追加, GROUP BYにDISTINCTを追加可能[ 57] [ 58]
15
000000002022-10-13-0000 2022年10月13日
サポート中: 15.7
000000002024-05-09-0000 2024年5月9日
000000002027-11-11-0000 2027年11月11日
標準SQLのMERGEコマンドの追加. PL/Python はPython 3 のみのサポートになり、plpythonu
は Python 3 になる, Python 2 のサポートは削除[ 59] [ 60]
16
000000002023-09-14-0000 2023年9月14日
現行バージョン: 16.3
000000002024-05-09-0000 2024年5月9日
000000002028-11-09-0000 2028年11月9日
論理レプリケーションの改善, pg_stat_io ビュー (I/O統計)[ 61]
凡例
サポート終了
サポート中
現行バージョン
最新プレビュー版
将来のリリース
PostgreSQLのバージョンは以下のように表現される。
6.0〜9.6:「x.y.z」(x、y、zはそれぞれ整数) で表現される。「x.y」の部分がメジャーバージョン、「z」がマイナーバージョンである[ 62] 。
10以降:整数部がメジャーバージョンを表現する[ 63] 。「x.y」(x、yはそれぞれ整数) で表現され、「x」の部分がメジャーバージョン、「y」がアップデート番号である。
注目すべきユーザー
PostgreSQLをプライマリデータベースとして使用している注目すべき組織や製品には、以下のようなものがある。
受賞
2008年の時点で、PostgreSQL は以下の受賞をしている[ 72] 。
1999 LinuxWorld Editor's Choice Award for Best Database
2000 Linux Journal Editors' Choice Awards for Best Database
2002 Linux New Media Editors Choice Award for Best Database
2003 Linux Journal Editors' Choice Awards for Best Database
2004 Linux New Media Award For Best Database
2004 Linux Journal Editors' Choice Awards for Best Database
2004 ArsTechnica Best Server Application Award
2005 Linux Journal Editors' Choice Awards for Best Database
2006 Linux Journal Editors' Choice Awards for Best Database
2008 Developer.com Product of the Year, Database Tool
注釈
出典
^ PostgreSQL: Documentation: 10: E.343. Release 6.0
^ a b c d e f g h i j k l m PostgreSQL: Documentation: 10: 2. A Brief History of PostgreSQL
^ "Out-of-cycle release scheduled for November 21, 2024" ; 出版日: 2024年11月21日.
^ マイケル・ストーンブレーカー (1986). “Object management in POSTGRES using procedures”. International Workshop on Object-Oriented Database Systems . IEEE Computer Society Press. ISBN 0-8186-0734-3
^ “Stack Overflow Developer Survey 2023 ”. Stack Overflow . 27 July 2024 閲覧。
^ “Technology | 2024 Stack Overflow Developer Survey ”. survey.stackoverflow.co . 27 July 2024 閲覧。
^ DB-Engines Ranking - popularity ranking of database management systems
^ historical trend of the popularity ranking of database management systems
^ a b “Software Stack Market Share: July 2012 ”. 2018年2月10日 閲覧。
^ “Package: mingw-w64-x86_64-postgresql - MSYS2 Packages ”. packages.msys2.org . 27 July 2024 閲覧。
^ “Cygwin Package Summary for postgresql ”. cygwin.com . 27 July 2024 閲覧。
^ PostgreSQL: Documentation: 10: Chapter 41. Procedural Languages
^ PostgreSQL: Documentation: 10: 37.9. C-Language Functions
^ PostgreSQL: Documentation: 10: H.3. Procedural Languages
^ 11.2. インデックスの種類
^ 第61章 GiSTインデックス
^ 第62章 SP-GiSTインデックス
^ 第63章 GINインデックス
^ 第64章 BRINインデックス
^ 第8章 データ型
^ PostgreSQL: Documentation: 10: 5.10. Table Partitioning
^ 第26章 高可用性、負荷分散およびレプリケーション
^ PostgreSQL: Documentation: 10: Chapter 31. Logical Replication
^ “「PostgreSQL 9.5」リリース ”. Impress Corporation (2016年1月9日). 2016年1月17日 閲覧。
^
“Documentation, Chapter 25. Backup and Restore ”. 1996-2020 The PostgreSQL Global Development Group (2020年). 1 Oct 2020 閲覧。
^ PostgreSQL 文書, "リリース8.0.2 "
^ OSS iPedia, "DBT-1によるPostgreSQL8.1の32ビットマシン(IA32)でのCPUスケーラビリティに関する考察(チューニング有り) "
^ OSS iPedia, "DBT-1によるパッチを適用したPostgreSQL8.1.2の32ビットマシン(IA32)でのCPUスケーラビリティに関する考察(チューニング有り) "
^ a b Robert Haas (2012年4月3日). “Did I Say 32 Cores? How about 64? ”. 2012年11月3日 閲覧。
^ Doug Tolbert (Unisys), "Scaling PostgreSQL on SMP Architectures -- An Update " (PGCon 2007)
^ Improve LWLock scalability - git.postgresql.org Git - postgresql.git/commitdiff
^ Increase the number of buffer mapping partitions to 128 - git.postgresql.org Git - postgresql.git/commitdiff
^ Read Scalability in PostgreSQL 9.5 | EnterpriseDB
^ 最新PostgreSQLはパフォーマンスが飛躍的に向上する!? – PostgreSQLのCPUスケーラビリティについて – | db tech showcase
^ 【PostgreSQLウォッチ】第35回 性能を大幅に改善するPostgreSQL 8.3の新機能「HOT」とは
^ “SPECjAppServer2004 Result ”. SPEC (2007年7月4日). 2009年1月2日 閲覧。
^ 第51章 フロントエンド/バックエンドプロトコル
^ “psycopg2 and the LGPL ”. 2019年8月19日 閲覧。
^ a b 日本PostgreSQLユーザ会の目的 | 日本PostgreSQLユーザ会
^ “リリースノート 8.0 ”. PostgreSQL 文書 (2005年1月19日). 2009年8月29日 閲覧。
^ “リリースノート 8.1 ”. PostgreSQL 文書 (2005年11月8日). 2009年8月29日 閲覧。
^ “リリースノート 8.2 ”. PostgreSQL 文書 (2006年12月5日). 2009年8月29日 閲覧。
^ “リリースノート 8.3 ”. PostgreSQL 文書 (2008年2月4日). 2009年8月29日 閲覧。
^ “リリースノート 8.4 ”. PostgreSQL 文書 (2009年7月1日). 2009年8月29日 閲覧。
^ “リリースノート 9.0 ”. PostgreSQL 文書 (2010年9月20日). 2010年10月6日 閲覧。
^ “リリースノート 9.1 ”. PostgreSQL 文書 (2011年9月12日). 2011年11月12日 閲覧。
^ “リリースノート 9.2 ”. PostgreSQL 文書 (2012年9月10日). 2012年11月3日 閲覧。
^ “Release 9.3 ”. PostgreSQL Documentation (2013年9月9日). 2013年9月9日 閲覧。
^ “Release 9.4 ”. PostgreSQL Documentation (2014年12月18日). 2015年8月19日 閲覧。
^ “Release 9.5 ”. PostgreSQL Documentation (2016年1月7日). 2016年5月23日 閲覧。
^ “E.1. Release 9.6 ”. PostgreSQL Documentation (2016年9月29日). 2016年10月1日 閲覧。
^ “E.1. Release 10.0 ”. PostgreSQL Documentation (2017年10月5日). 2017年10月8日 閲覧。
^ “E.2. Release 11 ”. PostgreSQL Documentation (2018年10月18日). 2018年11月9日 閲覧。
^ “PostgreSQL: PostgreSQL 12 Released!” . Postgresql News . https://www.postgresql.org/about/news/1976/ 2024年4月30日 閲覧。
^ “PostgreSQL 13 Release Notes ”. www.postgresql.org . 2024年4月30日 閲覧。
^ “PostgreSQL 13 Released! ”. www.postgresql.org . 2024年4月30日 閲覧。
^ “PostgreSQL 14 Release Notes ”. www.postgresql.org . 2024年4月30日 閲覧。
^ “PostgreSQL 14 Released! ”. www.postgresql.org . 2024年4月30日 閲覧。
^ “PostgreSQL 15 Release Notes ”. www.postgresql.org . 2024年4月30日 閲覧。
^ “PostgreSQL 15 Released! ”. www.postgresql.org . 2024年4月30日 閲覧。
^ “PostgreSQL 16 Released! ”. 2024年4月30日 閲覧。
^ 鈴木啓修「PostgreSQLと高可用性システム/大規模システム PostgreSQLの進化の足跡」『WEB+DB PRESS Vol.48』(初版第1刷)技術評論社、2009年1月25日、104頁。
^ Change in Version Numbering - New in postgres 10 - PostgreSQL wiki
^ a b c W. Jason Gilmore; R.H. Treat (2006). Beginning PHP and PostgreSQL 8: From Novice to Professional . Apress. ISBN 978-1-43020-136-6 . https://books.google.com/books?id=BiRC4JtQzFIC&pg=PA577 August 30, 2017 閲覧。
^ Pihlak. “PostgreSQL @Skype ”. wiki.postgresql.org . January 16, 2019 閲覧。
^ “Yandex.Mail's successful migration from Oracle to Postgres [pdf ]”. Hacker News: news.ycombinator.com . September 28, 2016 閲覧。
^ a b S. Riggs; G. Ciolli; H. Krosing; G. Bartolini (2015). PostgreSQL 9 Administration Cookbook - Second Edition . Packt. ISBN 978-1-84951-906-9 . https://books.google.com/books?id=rYrwCAAAQBAJ&pg=PA3 September 5, 2017 閲覧。
^ “Met Office swaps Oracle for PostgreSQL” . computerweekly.com . (June 17, 2014). https://www.computerweekly.com/ezine/Computer-Weekly/The-Met-Office-turns-to-open-source/Met-Office-swaps-Oracle-for-PostgreSQL September 5, 2017 閲覧。
^ “Open Source Software ”. FlightAware . November 22, 2017 閲覧。
^ “Ansible at Grofers (Part 2) — Managing PostgreSQL” . Lambda - The Grofers Engineering Blog . (February 28, 2017). https://lambda.grofers.com/ansible-at-grofers-part-2-managing-postgresql-c4069ce5855b September 5, 2018 閲覧。
^ McMahon, Philip; Chiorean, Maria-Livia; Coleman, Susie; Askoolum, Akash (November 30, 2018). “Digital Blog: Bye bye Mongo, Hello Postgres” (英語). The Guardian . ISSN 0261-3077 . https://www.theguardian.com/info/2018/nov/30/bye-bye-mongo-hello-postgres
^ PostgreSQL: Awards
参考書籍
外部リンク