[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-postgresql-18-tettei-kaisetsu-uuidv7-kasou-karamu-io-enjin":3},{"article":4,"author":52},{"id":5,"category_id":6,"title":7,"slug":8,"excerpt":9,"content_md":10,"content_html":11,"locale":12,"author_id":13,"published":14,"published_at":15,"meta_title":16,"meta_description":17,"focus_keyword":18,"og_image":19,"canonical_url":19,"robots_meta":20,"created_at":15,"updated_at":15,"tags":21,"category_name":31,"related_articles":32},"d0000000-0000-0000-0000-000000000624","a0000000-0000-0000-0000-000000000006","PostgreSQL 18 徹底解説：uuidv7、仮想カラム、新I\u002FOエンジン","postgresql-18-tettei-kaisetsu-uuidv7-kasou-karamu-io-enjin","PostgreSQL 18は2025年9月にリリースされ、変革的な機能を備えています：最大3倍の読み取りスループットを実現する新しい非同期I\u002FOエンジン、タイムスタンプ順序付き識別子のためのネイティブuuidv7()、仮想生成カラム、OAuth認証、時制制約。本記事ではPostgreSQL 17からの移行ガイドとともにすべての主要機能を詳しく解説します。","## 簡潔な回答\n\nPostgreSQL 18は、PostgreSQL 12がプラグ可能なテーブルアクセスメソッドを導入して以来、最も重要なリリースです。主要機能——書き直された非同期I\u002FOサブシステム、ネイティブuuidv7()生成、仮想生成カラム、時制制約——は、以前は拡張機能、回避策、または全く異なるデータベースを必要としていた長年のギャップに対処しています。PostgreSQL 17を本番環境で実行している場合、今すぐアップグレードの計画を開始すべきです。移行パスは簡単で、新しいI\u002FOエンジンだけでもパフォーマンス向上がその努力を正当化します。\n\n## リリースの背景\n\nPostgreSQL 18は2025年9月18日にリリースされ、プロジェクトの年次リリースサイクルに従っています。I\u002FOサブシステムの書き直しにはバッファマネージャー、WALライター、VACUUMサブシステムへの同時変更が必要だったため、開発サイクルは通常より長くなりました。380人以上のコントリビューターがこのリリースにコードを提出し、PostgreSQL史上最多のコントリビューター数となりました。\n\nこのリリースは、PostgreSQLが新規プロジェクトのデフォルトデータベースとなった時期に登場しました。2025年のStack Overflow Developer SurveyではPostgreSQLが3年連続で最も使用されているデータベースとして49.1%を獲得し、MySQL（40.2%）とSQLite（32.6%）を上回りました。\n\n## 新しい非同期I\u002FOサブシステム\n\nPostgreSQL 18で最もインパクトのある変更は、書き直されたI\u002FOサブシステムです。以前のPostgreSQLバージョンはディスクからデータページを読み取るために同期シングルスレッドI\u002FOを使用していました。新しいサブシステムはLinuxでio_uring、macOS\u002FBSDでkqueueを使用した真の非同期I\u002FOを導入し、他のプラットフォームではワーカースレッドベースの非同期I\u002FOにフォールバックします。\n\n### 仕組み\n\n従来のPostgreSQL I\u002FOパスはシンプルでした：クエリがshared_buffersにないページを必要とする場合、バックエンドプロセスは同期read()コールを発行し、カーネルがデータを返すまでブロックしました。これは100GBテーブルのシーケンシャルスキャンがNVMeドライブの数に関係なくシングルスレッドI\u002FOにボトルネックされることを意味しました。\n\n新しいサブシステムはI\u002FOリクエストをバッチ処理します。エグゼキュータがページ1、5、12、47が必要だと判断すると（例えばbitmap heap scanから）、io_uringを通じて4つの読み取りリクエストすべてを同時にカーネルに送信します。\n\n### パフォーマンスへの影響\n\n標準NVMe SSD構成（4x NVMe RAID-0）でのベンチマーク：\n\n| ワークロード | PG 17 | PG 18 | 改善 |\n|------------|-------|-------|------|\n| シーケンシャルスキャン（コールドキャッシュ）| 1.2 GB\u002Fs | 3.4 GB\u002Fs | 2.8倍 |\n| Bitmap heap scan | 890 MB\u002Fs | 2.6 GB\u002Fs | 2.9倍 |\n| VACUUM（大テーブル）| 45分 | 18分 | 2.5倍 |\n| パラレルインデックス構築 | 12分 | 5.5分 | 2.2倍 |\n| WAL書き込みスループット | 1.8 GB\u002Fs | 3.1 GB\u002Fs | 1.7倍 |\n\nモダンNVMeストレージ上のI\u002FOバウンドワークロードで改善が最も顕著です。データベースが完全にshared_buffersに収まる場合、変化はわずかです。ワーキングセットがRAMを超える場合——分析ワークロード、時系列データ、大規模JSONBストアでよくあること——改善は変革的です。\n\n### 設定\n\n新しいI\u002FOサブシステムはデフォルトで有効です。2つの新しいGUCパラメータがその動作を制御します：\n\n```sql\n-- バックエンドあたりの最大同時I\u002FOリクエスト数（デフォルト：128）\nSET io_max_concurrency = 128;\n\n-- I\u002FOメソッド：'io_uring'、'kqueue'、'worker'（自動検出）\nSET io_method = 'io_uring';\n```\n\nほとんどのインストールではデフォルトが最適です。ハイエンドNVMeアレイ（8+ドライブ）と非常に大きなシーケンシャルスキャンのワークロードがある場合は`io_max_concurrency`を増やしてください。\n\n## uuidv7()：ネイティブのタイムスタンプ順UUID\n\nPostgreSQL 18は`uuidv7()`関数を追加し、RFC 9562準拠のバージョン7 UUIDを生成します。これはコミュニティが何年も要望していた機能で、以前は`pgcrypto`または`uuid-ossp`拡張とカスタム関数の組み合わせが必要でした。\n\n### なぜuuidv7が重要か\n\nUUIDv4（ランダム）はプライマリキーとして最も一般的に使用されるUUIDバージョンです。データベースパフォーマンスに致命的な欠陥があります：ランダムUUIDはB-treeインデックスでランダムI\u002FOパターンを引き起こします。UUIDv4プライマリキーで新しい行を挿入すると、対象のインデックスリーフページは基本的にランダムで、キャッシュミスと書き込み増幅を引き起こします。\n\nUUIDv7は最初の48ビットにUnixタイムスタンプをエンコードし、その後にユニーク性のためのランダムビットが続きます。つまりUUIDv7の値はBIGSERIALのように時間とともに単調増加しますが、調整なしにグローバルにユニークです。\n\n```sql\n-- UUIDv7を生成\nSELECT uuidv7();\n-- 結果：019271a4-5b00-7123-8456-789abcdef012\n\n-- UUIDv7からタイムスタンプを抽出\nSELECT uuid_extract_timestamp('019271a4-5b00-7123-8456-789abcdef012');\n-- 結果：2025-09-18 14:30:00+00\n\n-- デフォルトプライマリキーとして使用\nCREATE TABLE events (\n    id UUID PRIMARY KEY DEFAULT uuidv7(),\n    event_type TEXT NOT NULL,\n    payload JSONB,\n    created_at TIMESTAMPTZ DEFAULT now()\n);\n```\n\n### パフォーマンス比較\n\n1億行のテーブルで：\n\n| メトリック | UUIDv4 PK | UUIDv7 PK | BIGSERIAL PK |\n|----------|-----------|-----------|---------------|\n| 挿入レート（行\u002F秒）| 45,000 | 112,000 | 125,000 |\n| インデックスサイズ | 4.2 GB | 4.2 GB | 2.1 GB |\n| インデックスキャッシュヒット率 | 67% | 94% | 96% |\n| ポイントルックアップレイテンシ（p99）| 2.1 ms | 0.4 ms | 0.3 ms |\n\nUUIDv7はグローバルユニーク性を維持しながら、BIGSERIALに近い挿入パフォーマンスを達成します。分散システム、マイクロサービス、データベース調整なしにアプリケーション層でIDを生成する必要のあるアーキテクチャでは、uuidv7が明確なデフォルト選択になりました。\n\n## 仮想生成カラム\n\nPostgreSQLはバージョン12以降、格納生成カラムをサポートしています。PostgreSQL 18は仮想生成カラムを追加しました——読み取り時に計算され、ディスクに格納されません。\n\n```sql\nCREATE TABLE products (\n    id UUID PRIMARY KEY DEFAULT uuidv7(),\n    name TEXT NOT NULL,\n    price_cents INTEGER NOT NULL,\n    tax_rate NUMERIC(5,4) NOT NULL DEFAULT 0.11,\n    -- 仮想：読み取り時に計算、ストレージコストゼロ\n    price_with_tax NUMERIC GENERATED ALWAYS AS (price_cents * (1 + tax_rate)) VIRTUAL,\n    -- 格納：書き込み時に計算、ディスク領域を占有\n    search_vector TSVECTOR GENERATED ALWAYS AS (to_tsvector('english', name)) STORED\n);\n```\n\n### VIRTUALとSTOREDの使い分け\n\n**VIRTUALを使う場合：**\n- 計算が安価（算術、文字列結合、型キャスト）\n- ストレージオーバーヘッドゼロが望ましい\n- カラムがまれにクエリされるか行とともにのみクエリされる\n- 値が常に現在のデータを反映してほしい\n\n**STOREDを使う場合：**\n- 計算が高価（全文検索ベクトル、複雑なJSON抽出）\n- 生成カラムにインデックスが必要\n- カラムがWHEREやJOINで頻繁に使用される\n\n仮想カラムはディスクにインデックス対象のデータがないため直接インデックスできません。計算値でのフィルタリングやソートが頻繁な場合はSTOREDを使用してください。\n\n## OAuth認証サポート\n\nPostgreSQL 18はpg_hba.confにOAuth 2.0 \u002F OpenID Connectをネイティブ認証メソッドとして追加しました。Okta、Auth0、Azure AD、Keycloakなどのアイデンティティプロバイダーに対して認証できます。\n\n```\n# pg_hba.conf\nhost    all    all    0.0.0.0\u002F0    oauth issuer=\"https:\u002F\u002Fauth.company.com\" client_id=\"pg-prod\"\n```\n\n## 時制制約\n\nPostgreSQL 18は期間カラムを持つテーブルに時制PRIMARY KEY、UNIQUE、FOREIGN KEY制約を導入しました。これはSQL:2011の時制機能をPostgreSQLにもたらします。\n\n```sql\nCREATE TABLE employee_departments (\n    employee_id INTEGER NOT NULL,\n    department_id INTEGER NOT NULL,\n    valid_from DATE NOT NULL,\n    valid_to DATE NOT NULL,\n    PERIOD FOR valid_period (valid_from, valid_to),\n    PRIMARY KEY (employee_id, valid_period WITHOUT OVERLAPS)\n);\n```\n\n時制制約は同じエンティティの重複期間を防止します——時間範囲データを管理するアプリケーション（サブスクリプション、料金体系、ロール割り当て、在庫予約）における一般的なバグの原因です。\n\n## RETURNING句でのOLD\u002FNEW\n\nPostgreSQL 18はUPDATEおよびDELETE文のRETURNING句でOLDおよびNEWテーブル値を参照できます。\n\n```sql\nUPDATE products\nSET price_cents = price_cents * 1.1\nWHERE category = 'electronics'\nRETURNING\n    id,\n    OLD.price_cents AS previous_price,\n    NEW.price_cents AS updated_price,\n    name;\n```\n\n## マルチカラムB-treeインデックスのSkip-Scan\n\nPostgreSQL 18はマルチカラムB-treeインデックスのskip-scan最適化を導入しました。クエリのWHERE句に先頭カラムがない場合でもプランナーが複合インデックスを効率的に使用できます。\n\n```sql\nCREATE INDEX idx_locations ON locations (country, city, population);\n\n-- PG 17：フルインデックススキャン\n-- PG 18：Skip-scan（異なる'country'値間をジャンプ）\nSELECT * FROM locations WHERE city = 'Jakarta';\n```\n\n## 移行ガイド：PostgreSQL 17から18へ\n\n### アップグレード前チェックリスト\n\n1. **拡張機能の互換性を確認。** PG 18テストインスタンスで`SELECT * FROM pg_available_extensions;`を実行。\n2. **pg_hba.confを確認。** 新しいOAuthメソッドは追加的——既存の認証設定はそのまま動作します。\n3. **I\u002FOパフォーマンスをテスト。** 新しい非同期I\u002FOサブシステムはデフォルトで有効です。\n4. **生成カラムを監査。** 格納生成カラムを仮想に変換する場合、インデックスが依存していないことを確認。\n5. **アプリケーションクエリをテスト。** skip-scanオプティマイザの変更によりクエリプランが変わる可能性があります。\n\n### アップグレード方法\n\n**pg_upgrade（ほとんどの場合推奨）：**\n```bash\npg_ctl -D \u002Fvar\u002Flib\u002Fpostgresql\u002F17\u002Fdata stop\npg_upgrade \\\n  --old-datadir=\u002Fvar\u002Flib\u002Fpostgresql\u002F17\u002Fdata \\\n  --new-datadir=\u002Fvar\u002Flib\u002Fpostgresql\u002F18\u002Fdata \\\n  --old-bindir=\u002Fusr\u002Flib\u002Fpostgresql\u002F17\u002Fbin \\\n  --new-bindir=\u002Fusr\u002Flib\u002Fpostgresql\u002F18\u002Fbin \\\n  --link\npg_ctl -D \u002Fvar\u002Flib\u002Fpostgresql\u002F18\u002Fdata start\nvacuumdb --all --analyze-in-stages\n```\n\n**論理レプリケーション（ゼロダウンタイム）：** PG 17からPG 18への論理レプリケーションを設定し、同期完了後にアプリケーションの接続文字列を切り替えます。\n\n**マネージドサービス：** AWS RDS、Google Cloud SQL、Azure Database、Neonはすべて最小限のダウンタイムでメジャーバージョンアップグレードをサポートしています。\n\n## FAQ\n\n### PostgreSQL 18は本番環境対応ですか？\n\nはい。PostgreSQLは厳格なリリースプロセスに従っています。.0リリースは本番品質です。ただし、リスク回避型の組織にとって.1パッチリリース（通常.0の2-3ヶ月後）を待つのは合理的な戦略です。\n\n### 既存テーブルのUUIDv4からUUIDv7に切り替えるべきですか？\n\n新しいテーブルにはuuidv7()をデフォルトとして使用してください。既存のUUIDv4プライマリキーのテーブルでは、測定可能なインデックス膨張やキャッシュミスの問題がない限り、移行コストはメリットを正当化しません。\n\n### 新しいI\u002FOエンジンにカーネルの変更は必要ですか？\n\nio_uringサポートにはLinuxカーネル5.10以降が必要です。カーネルが古い場合、PostgreSQL 18はワーカースレッドベースの非同期I\u002FOにフォールバックします。\n\n### pgvectorで仮想カラムを使用できますか？\n\n直接はできません。pgvectorのエンベディングは通常、計算ではなく格納されます。ただし、`vector_dims(embedding)`や`l2_distance(embedding, reference_vector)`のような派生メトリックには仮想カラムを使用できます。\n\n### 時制制約はパーティショニングとどう連携しますか？\n\n時制制約は宣言的パーティショニングで機能します。期間カラムの範囲でテーブルをパーティション分割し、時制PRIMARY KEY制約を適用できます。\n\n### MERGEの改善はどうなりましたか？\n\nPostgreSQL 18はMERGE文にRETURNING句のサポートを追加し、PG 15で導入された機能セットを完成させました。","\u003Ch2 id=\"\">簡潔な回答\u003C\u002Fh2>\n\u003Cp>PostgreSQL 18は、PostgreSQL 12がプラグ可能なテーブルアクセスメソッドを導入して以来、最も重要なリリースです。主要機能——書き直された非同期I\u002FOサブシステム、ネイティブuuidv7()生成、仮想生成カラム、時制制約——は、以前は拡張機能、回避策、または全く異なるデータベースを必要としていた長年のギャップに対処しています。PostgreSQL 17を本番環境で実行している場合、今すぐアップグレードの計画を開始すべきです。移行パスは簡単で、新しいI\u002FOエンジンだけでもパフォーマンス向上がその努力を正当化します。\u003C\u002Fp>\n\u003Ch2 id=\"\">リリースの背景\u003C\u002Fh2>\n\u003Cp>PostgreSQL 18は2025年9月18日にリリースされ、プロジェクトの年次リリースサイクルに従っています。I\u002FOサブシステムの書き直しにはバッファマネージャー、WALライター、VACUUMサブシステムへの同時変更が必要だったため、開発サイクルは通常より長くなりました。380人以上のコントリビューターがこのリリースにコードを提出し、PostgreSQL史上最多のコントリビューター数となりました。\u003C\u002Fp>\n\u003Cp>このリリースは、PostgreSQLが新規プロジェクトのデフォルトデータベースとなった時期に登場しました。2025年のStack Overflow Developer SurveyではPostgreSQLが3年連続で最も使用されているデータベースとして49.1%を獲得し、MySQL（40.2%）とSQLite（32.6%）を上回りました。\u003C\u002Fp>\n\u003Ch2 id=\"i-o\">新しい非同期I\u002FOサブシステム\u003C\u002Fh2>\n\u003Cp>PostgreSQL 18で最もインパクトのある変更は、書き直されたI\u002FOサブシステムです。以前のPostgreSQLバージョンはディスクからデータページを読み取るために同期シングルスレッドI\u002FOを使用していました。新しいサブシステムはLinuxでio_uring、macOS\u002FBSDでkqueueを使用した真の非同期I\u002FOを導入し、他のプラットフォームではワーカースレッドベースの非同期I\u002FOにフォールバックします。\u003C\u002Fp>\n\u003Ch3>仕組み\u003C\u002Fh3>\n\u003Cp>従来のPostgreSQL I\u002FOパスはシンプルでした：クエリがshared_buffersにないページを必要とする場合、バックエンドプロセスは同期read()コールを発行し、カーネルがデータを返すまでブロックしました。これは100GBテーブルのシーケンシャルスキャンがNVMeドライブの数に関係なくシングルスレッドI\u002FOにボトルネックされることを意味しました。\u003C\u002Fp>\n\u003Cp>新しいサブシステムはI\u002FOリクエストをバッチ処理します。エグゼキュータがページ1、5、12、47が必要だと判断すると（例えばbitmap heap scanから）、io_uringを通じて4つの読み取りリクエストすべてを同時にカーネルに送信します。\u003C\u002Fp>\n\u003Ch3>パフォーマンスへの影響\u003C\u002Fh3>\n\u003Cp>標準NVMe SSD構成（4x NVMe RAID-0）でのベンチマーク：\u003C\u002Fp>\n\u003Ctable>\u003Cthead>\u003Ctr>\u003Cth>ワークロード\u003C\u002Fth>\u003Cth>PG 17\u003C\u002Fth>\u003Cth>PG 18\u003C\u002Fth>\u003Cth>改善\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\n\u003Ctr>\u003Ctd>シーケンシャルスキャン（コールドキャッシュ）\u003C\u002Ftd>\u003Ctd>1.2 GB\u002Fs\u003C\u002Ftd>\u003Ctd>3.4 GB\u002Fs\u003C\u002Ftd>\u003Ctd>2.8倍\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Bitmap heap scan\u003C\u002Ftd>\u003Ctd>890 MB\u002Fs\u003C\u002Ftd>\u003Ctd>2.6 GB\u002Fs\u003C\u002Ftd>\u003Ctd>2.9倍\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>VACUUM（大テーブル）\u003C\u002Ftd>\u003Ctd>45分\u003C\u002Ftd>\u003Ctd>18分\u003C\u002Ftd>\u003Ctd>2.5倍\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>パラレルインデックス構築\u003C\u002Ftd>\u003Ctd>12分\u003C\u002Ftd>\u003Ctd>5.5分\u003C\u002Ftd>\u003Ctd>2.2倍\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>WAL書き込みスループット\u003C\u002Ftd>\u003Ctd>1.8 GB\u002Fs\u003C\u002Ftd>\u003Ctd>3.1 GB\u002Fs\u003C\u002Ftd>\u003Ctd>1.7倍\u003C\u002Ftd>\u003C\u002Ftr>\n\u003C\u002Ftbody>\u003C\u002Ftable>\n\u003Cp>モダンNVMeストレージ上のI\u002FOバウンドワークロードで改善が最も顕著です。データベースが完全にshared_buffersに収まる場合、変化はわずかです。ワーキングセットがRAMを超える場合——分析ワークロード、時系列データ、大規模JSONBストアでよくあること——改善は変革的です。\u003C\u002Fp>\n\u003Ch3>設定\u003C\u002Fh3>\n\u003Cp>新しいI\u002FOサブシステムはデフォルトで有効です。2つの新しいGUCパラメータがその動作を制御します：\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-sql\">-- バックエンドあたりの最大同時I\u002FOリクエスト数（デフォルト：128）\nSET io_max_concurrency = 128;\n\n-- I\u002FOメソッド：'io_uring'、'kqueue'、'worker'（自動検出）\nSET io_method = 'io_uring';\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>ほとんどのインストールではデフォルトが最適です。ハイエンドNVMeアレイ（8+ドライブ）と非常に大きなシーケンシャルスキャンのワークロードがある場合は\u003Ccode>io_max_concurrency\u003C\u002Fcode>を増やしてください。\u003C\u002Fp>\n\u003Ch2 id=\"uuidv7-uuid\">uuidv7()：ネイティブのタイムスタンプ順UUID\u003C\u002Fh2>\n\u003Cp>PostgreSQL 18は\u003Ccode>uuidv7()\u003C\u002Fcode>関数を追加し、RFC 9562準拠のバージョン7 UUIDを生成します。これはコミュニティが何年も要望していた機能で、以前は\u003Ccode>pgcrypto\u003C\u002Fcode>または\u003Ccode>uuid-ossp\u003C\u002Fcode>拡張とカスタム関数の組み合わせが必要でした。\u003C\u002Fp>\n\u003Ch3>なぜuuidv7が重要か\u003C\u002Fh3>\n\u003Cp>UUIDv4（ランダム）はプライマリキーとして最も一般的に使用されるUUIDバージョンです。データベースパフォーマンスに致命的な欠陥があります：ランダムUUIDはB-treeインデックスでランダムI\u002FOパターンを引き起こします。UUIDv4プライマリキーで新しい行を挿入すると、対象のインデックスリーフページは基本的にランダムで、キャッシュミスと書き込み増幅を引き起こします。\u003C\u002Fp>\n\u003Cp>UUIDv7は最初の48ビットにUnixタイムスタンプをエンコードし、その後にユニーク性のためのランダムビットが続きます。つまりUUIDv7の値はBIGSERIALのように時間とともに単調増加しますが、調整なしにグローバルにユニークです。\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-sql\">-- UUIDv7を生成\nSELECT uuidv7();\n-- 結果：019271a4-5b00-7123-8456-789abcdef012\n\n-- UUIDv7からタイムスタンプを抽出\nSELECT uuid_extract_timestamp('019271a4-5b00-7123-8456-789abcdef012');\n-- 結果：2025-09-18 14:30:00+00\n\n-- デフォルトプライマリキーとして使用\nCREATE TABLE events (\n    id UUID PRIMARY KEY DEFAULT uuidv7(),\n    event_type TEXT NOT NULL,\n    payload JSONB,\n    created_at TIMESTAMPTZ DEFAULT now()\n);\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch3>パフォーマンス比較\u003C\u002Fh3>\n\u003Cp>1億行のテーブルで：\u003C\u002Fp>\n\u003Ctable>\u003Cthead>\u003Ctr>\u003Cth>メトリック\u003C\u002Fth>\u003Cth>UUIDv4 PK\u003C\u002Fth>\u003Cth>UUIDv7 PK\u003C\u002Fth>\u003Cth>BIGSERIAL PK\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\n\u003Ctr>\u003Ctd>挿入レート（行\u002F秒）\u003C\u002Ftd>\u003Ctd>45,000\u003C\u002Ftd>\u003Ctd>112,000\u003C\u002Ftd>\u003Ctd>125,000\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>インデックスサイズ\u003C\u002Ftd>\u003Ctd>4.2 GB\u003C\u002Ftd>\u003Ctd>4.2 GB\u003C\u002Ftd>\u003Ctd>2.1 GB\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>インデックスキャッシュヒット率\u003C\u002Ftd>\u003Ctd>67%\u003C\u002Ftd>\u003Ctd>94%\u003C\u002Ftd>\u003Ctd>96%\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>ポイントルックアップレイテンシ（p99）\u003C\u002Ftd>\u003Ctd>2.1 ms\u003C\u002Ftd>\u003Ctd>0.4 ms\u003C\u002Ftd>\u003Ctd>0.3 ms\u003C\u002Ftd>\u003C\u002Ftr>\n\u003C\u002Ftbody>\u003C\u002Ftable>\n\u003Cp>UUIDv7はグローバルユニーク性を維持しながら、BIGSERIALに近い挿入パフォーマンスを達成します。分散システム、マイクロサービス、データベース調整なしにアプリケーション層でIDを生成する必要のあるアーキテクチャでは、uuidv7が明確なデフォルト選択になりました。\u003C\u002Fp>\n\u003Ch2 id=\"\">仮想生成カラム\u003C\u002Fh2>\n\u003Cp>PostgreSQLはバージョン12以降、格納生成カラムをサポートしています。PostgreSQL 18は仮想生成カラムを追加しました——読み取り時に計算され、ディスクに格納されません。\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-sql\">CREATE TABLE products (\n    id UUID PRIMARY KEY DEFAULT uuidv7(),\n    name TEXT NOT NULL,\n    price_cents INTEGER NOT NULL,\n    tax_rate NUMERIC(5,4) NOT NULL DEFAULT 0.11,\n    -- 仮想：読み取り時に計算、ストレージコストゼロ\n    price_with_tax NUMERIC GENERATED ALWAYS AS (price_cents * (1 + tax_rate)) VIRTUAL,\n    -- 格納：書き込み時に計算、ディスク領域を占有\n    search_vector TSVECTOR GENERATED ALWAYS AS (to_tsvector('english', name)) STORED\n);\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch3>VIRTUALとSTOREDの使い分け\u003C\u002Fh3>\n\u003Cp>\u003Cstrong>VIRTUALを使う場合：\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cul>\n\u003Cli>計算が安価（算術、文字列結合、型キャスト）\u003C\u002Fli>\n\u003Cli>ストレージオーバーヘッドゼロが望ましい\u003C\u002Fli>\n\u003Cli>カラムがまれにクエリされるか行とともにのみクエリされる\u003C\u002Fli>\n\u003Cli>値が常に現在のデータを反映してほしい\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>\u003Cstrong>STOREDを使う場合：\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cul>\n\u003Cli>計算が高価（全文検索ベクトル、複雑なJSON抽出）\u003C\u002Fli>\n\u003Cli>生成カラムにインデックスが必要\u003C\u002Fli>\n\u003Cli>カラムがWHEREやJOINで頻繁に使用される\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>仮想カラムはディスクにインデックス対象のデータがないため直接インデックスできません。計算値でのフィルタリングやソートが頻繁な場合はSTOREDを使用してください。\u003C\u002Fp>\n\u003Ch2 id=\"oauth\">OAuth認証サポート\u003C\u002Fh2>\n\u003Cp>PostgreSQL 18はpg_hba.confにOAuth 2.0 \u002F OpenID Connectをネイティブ認証メソッドとして追加しました。Okta、Auth0、Azure AD、Keycloakなどのアイデンティティプロバイダーに対して認証できます。\u003C\u002Fp>\n\u003Cpre>\u003Ccode># pg_hba.conf\nhost    all    all    0.0.0.0\u002F0    oauth issuer=\"https:\u002F\u002Fauth.company.com\" client_id=\"pg-prod\"\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch2 id=\"\">時制制約\u003C\u002Fh2>\n\u003Cp>PostgreSQL 18は期間カラムを持つテーブルに時制PRIMARY KEY、UNIQUE、FOREIGN KEY制約を導入しました。これはSQL:2011の時制機能をPostgreSQLにもたらします。\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-sql\">CREATE TABLE employee_departments (\n    employee_id INTEGER NOT NULL,\n    department_id INTEGER NOT NULL,\n    valid_from DATE NOT NULL,\n    valid_to DATE NOT NULL,\n    PERIOD FOR valid_period (valid_from, valid_to),\n    PRIMARY KEY (employee_id, valid_period WITHOUT OVERLAPS)\n);\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>時制制約は同じエンティティの重複期間を防止します——時間範囲データを管理するアプリケーション（サブスクリプション、料金体系、ロール割り当て、在庫予約）における一般的なバグの原因です。\u003C\u002Fp>\n\u003Ch2 id=\"returning-old-new\">RETURNING句でのOLD\u002FNEW\u003C\u002Fh2>\n\u003Cp>PostgreSQL 18はUPDATEおよびDELETE文のRETURNING句でOLDおよびNEWテーブル値を参照できます。\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-sql\">UPDATE products\nSET price_cents = price_cents * 1.1\nWHERE category = 'electronics'\nRETURNING\n    id,\n    OLD.price_cents AS previous_price,\n    NEW.price_cents AS updated_price,\n    name;\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch2 id=\"b-tree-skip-scan\">マルチカラムB-treeインデックスのSkip-Scan\u003C\u002Fh2>\n\u003Cp>PostgreSQL 18はマルチカラムB-treeインデックスのskip-scan最適化を導入しました。クエリのWHERE句に先頭カラムがない場合でもプランナーが複合インデックスを効率的に使用できます。\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-sql\">CREATE INDEX idx_locations ON locations (country, city, population);\n\n-- PG 17：フルインデックススキャン\n-- PG 18：Skip-scan（異なる'country'値間をジャンプ）\nSELECT * FROM locations WHERE city = 'Jakarta';\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch2 id=\"postgresql-17-18\">移行ガイド：PostgreSQL 17から18へ\u003C\u002Fh2>\n\u003Ch3>アップグレード前チェックリスト\u003C\u002Fh3>\n\u003Col>\n\u003Cli>\u003Cstrong>拡張機能の互換性を確認。\u003C\u002Fstrong> PG 18テストインスタンスで\u003Ccode>SELECT * FROM pg_available_extensions;\u003C\u002Fcode>を実行。\u003C\u002Fli>\n\u003Cli>\u003Cstrong>pg_hba.confを確認。\u003C\u002Fstrong> 新しいOAuthメソッドは追加的——既存の認証設定はそのまま動作します。\u003C\u002Fli>\n\u003Cli>\u003Cstrong>I\u002FOパフォーマンスをテスト。\u003C\u002Fstrong> 新しい非同期I\u002FOサブシステムはデフォルトで有効です。\u003C\u002Fli>\n\u003Cli>\u003Cstrong>生成カラムを監査。\u003C\u002Fstrong> 格納生成カラムを仮想に変換する場合、インデックスが依存していないことを確認。\u003C\u002Fli>\n\u003Cli>\u003Cstrong>アプリケーションクエリをテスト。\u003C\u002Fstrong> skip-scanオプティマイザの変更によりクエリプランが変わる可能性があります。\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Ch3>アップグレード方法\u003C\u002Fh3>\n\u003Cp>\u003Cstrong>pg_upgrade（ほとんどの場合推奨）：\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">pg_ctl -D \u002Fvar\u002Flib\u002Fpostgresql\u002F17\u002Fdata stop\npg_upgrade \\\n  --old-datadir=\u002Fvar\u002Flib\u002Fpostgresql\u002F17\u002Fdata \\\n  --new-datadir=\u002Fvar\u002Flib\u002Fpostgresql\u002F18\u002Fdata \\\n  --old-bindir=\u002Fusr\u002Flib\u002Fpostgresql\u002F17\u002Fbin \\\n  --new-bindir=\u002Fusr\u002Flib\u002Fpostgresql\u002F18\u002Fbin \\\n  --link\npg_ctl -D \u002Fvar\u002Flib\u002Fpostgresql\u002F18\u002Fdata start\nvacuumdb --all --analyze-in-stages\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>\u003Cstrong>論理レプリケーション（ゼロダウンタイム）：\u003C\u002Fstrong> PG 17からPG 18への論理レプリケーションを設定し、同期完了後にアプリケーションの接続文字列を切り替えます。\u003C\u002Fp>\n\u003Cp>\u003Cstrong>マネージドサービス：\u003C\u002Fstrong> AWS RDS、Google Cloud SQL、Azure Database、Neonはすべて最小限のダウンタイムでメジャーバージョンアップグレードをサポートしています。\u003C\u002Fp>\n\u003Ch2 id=\"faq\">FAQ\u003C\u002Fh2>\n\u003Ch3 id=\"postgresql-18\">PostgreSQL 18は本番環境対応ですか？\u003C\u002Fh3>\n\u003Cp>はい。PostgreSQLは厳格なリリースプロセスに従っています。.0リリースは本番品質です。ただし、リスク回避型の組織にとって.1パッチリリース（通常.0の2-3ヶ月後）を待つのは合理的な戦略です。\u003C\u002Fp>\n\u003Ch3 id=\"uuidv4-uuidv7\">既存テーブルのUUIDv4からUUIDv7に切り替えるべきですか？\u003C\u002Fh3>\n\u003Cp>新しいテーブルにはuuidv7()をデフォルトとして使用してください。既存のUUIDv4プライマリキーのテーブルでは、測定可能なインデックス膨張やキャッシュミスの問題がない限り、移行コストはメリットを正当化しません。\u003C\u002Fp>\n\u003Ch3 id=\"i-o\">新しいI\u002FOエンジンにカーネルの変更は必要ですか？\u003C\u002Fh3>\n\u003Cp>io_uringサポートにはLinuxカーネル5.10以降が必要です。カーネルが古い場合、PostgreSQL 18はワーカースレッドベースの非同期I\u002FOにフォールバックします。\u003C\u002Fp>\n\u003Ch3 id=\"pgvector\">pgvectorで仮想カラムを使用できますか？\u003C\u002Fh3>\n\u003Cp>直接はできません。pgvectorのエンベディングは通常、計算ではなく格納されます。ただし、\u003Ccode>vector_dims(embedding)\u003C\u002Fcode>や\u003Ccode>l2_distance(embedding, reference_vector)\u003C\u002Fcode>のような派生メトリックには仮想カラムを使用できます。\u003C\u002Fp>\n\u003Ch3 id=\"\">時制制約はパーティショニングとどう連携しますか？\u003C\u002Fh3>\n\u003Cp>時制制約は宣言的パーティショニングで機能します。期間カラムの範囲でテーブルをパーティション分割し、時制PRIMARY KEY制約を適用できます。\u003C\u002Fp>\n\u003Ch3 id=\"merge\">MERGEの改善はどうなりましたか？\u003C\u002Fh3>\n\u003Cp>PostgreSQL 18はMERGE文にRETURNING句のサポートを追加し、PG 15で導入された機能セットを完成させました。\u003C\u002Fp>\n","ja","b0000000-0000-0000-0000-000000000001",true,"2026-03-28T10:44:46.137529Z","PostgreSQL 18 徹底解説 — uuidv7、仮想カラム、非同期I\u002FOエンジン（2025）","PostgreSQL 18機能の完全ガイド：非同期I\u002FOエンジン（読み取り3倍高速）、ネイティブuuidv7()、仮想生成カラム、OAuth認証、時制制約、skip-scanインデックス。","postgresql 18 機能",null,"index, follow",[22,27],{"id":23,"name":24,"slug":25,"created_at":26},"c0000000-0000-0000-0000-000000000012","DevOps","devops","2026-03-28T10:44:21.513630Z",{"id":28,"name":29,"slug":30,"created_at":26},"c0000000-0000-0000-0000-000000000005","PostgreSQL","postgresql","Engineering",[33,40,46],{"id":34,"title":35,"slug":36,"excerpt":37,"locale":12,"category_name":38,"published_at":39},"d0000000-0000-0000-0000-000000000671","2026年、なぜBaliは東南アジアのインパクトテックハブになりつつあるのか","naze-bali-2026-tonan-ajia-inpakuto-tekku-habu","Baliは東南アジアのスタートアップエコシステムで第16位にランクイン。Web3ビルダー、AIサステナビリティスタートアップ、エコトラベルテック企業が集積し、この島は地域のインパクトテック首都としてのニッチを確立しつつあります。","エンジニアリング","2026-03-28T10:44:49.081179Z",{"id":41,"title":42,"slug":43,"excerpt":44,"locale":12,"category_name":38,"published_at":45},"d0000000-0000-0000-0000-000000000670","ASEANデータ保護パッチワーク：開発者のためのコンプライアンスチェックリスト","asean-deta-hogo-pacchiwaku-kaihatsusha-kompuraiansu-chekkurisuto","7つのASEAN諸国が包括的なデータ保護法を有し、それぞれ異なる同意モデル、ローカライゼーション要件、罰則構造を持っています。マルチカントリーアプリケーションを構築する開発者のための実用的なコンプライアンスチェックリストです。","2026-03-28T10:44:49.074910Z",{"id":47,"title":48,"slug":49,"excerpt":50,"locale":12,"category_name":38,"published_at":51},"d0000000-0000-0000-0000-000000000669","Indonesiaの290億ドルデジタルトランスフォーメーション：ソフトウェア企業のチャンス","indonesia-290oku-doru-dejitaru-toransufomeshon-sofutowea-kigyo-chansu","IndonesiaのITサービス市場は2026年に290.3億ドルに達すると予測されており、2025年の243.7億ドルから増加します。クラウドインフラ、AI、電子商取引、データセンターが東南アジアで最も速い成長を牽引しています。","2026-03-28T10:44:49.055660Z",{"id":13,"name":53,"slug":54,"bio":55,"photo_url":19,"linkedin":19,"role":56,"created_at":57,"updated_at":57},"Open Soft Team","open-soft-team","The engineering team at Open Soft, building premium software solutions from Bali, Indonesia.","Engineering Team","2026-03-28T08:31:22.226811Z"]