プラットフォームチームの菅原です。 最近、pistachioという宣言的スキーマ管理ツールを作成し[1]、本番環境のDBマイグレーションに導入したので紹介させてください。 pistachioについて 「宣言的スキーマ管理」はTerraformのように「あるべきスキーマの状態」を記述し、差分を埋めるDDLを実行することでDBマイグレーションを行う方法です。 同様のツールとしてはatlasやsqldef、拙作ですがRidgepole、最近のものだとpgschemaなどがあります。 pistachioはPostgreSQL専用の宣言的スキーマ管理ツールで、SQLでスキーマを記述して管理します。 pistachioのワークフロー まずdumpコマンドで既存のスキーマをファイルに出力します。 $ pist dump > schema.sql $ cat schema.sql -- Dump of s

Note We've updated our use of the term "row-level isolation" to "shared-schema" in this article to avoid confusion with Postgres RLS. We do not recommend relying on Postgres RLS. Multi-tenancy is a term used across various kinds of technical infrastructure, including application hosting, compute, databases, and more. For example, you may purchase cloud services from a provider, but your account is

In the previous article we covered how the PostgreSQL planner reads pg_class and pg_statistic to estimate row counts, choose join strategies, and decide whether an index scan is worth it. The message was clear: when statistics are wrong, everything else goes with it. Streaming replication provides bit-to-bit replication, so all replicas share the same statistics with primary server. But there was

こんにちは！ デジスマチームの山田です。これはデジスマチームのブログリレー3日目の投稿です。 本番稼動中のデータベースの運用において、NOT NULL制約を持たせたいカラムを既存のテーブルに追加する作業は頭を悩ませるものです。PostgreSQL 11（以下、PG11）以降、DEFAULTを固定の値で指定した場合のカラム追加は高速化されました。しかしDEFAULTとして固定値を用意するのではなく、各行ごとに異なる値の非NULLなカラムを追加したいというケースもあります。このような場合「一度NULLを許可してカラムを追加し、アプリケーションの改修やUPDATEによるバックフィルを完了させた後にNOT NULL制約を追加する」という手順を踏むことがあります。この際テーブルが長時間ロックされることを避けるためにCHECK制約を介した少し複雑な手順が必要でした。 そんな中PostgreSQL 18

概要 本書は、PostgreSQLの基本概念から安定稼働・パフォーマンスチューニング、そして現場で役立つ機能までを網羅した、実践的な解説書です。基礎的な解説からはじめ、PostgreSQLの内部構造、テーブル設計、レプリケーション、認証、バックアップ、リストア、モニタリングなどPostgreSQLを現場で利用するための知識を体系的に網羅しています。PostgreSQLの研究開発に従事し、PostgreSQL自身や周辺ツールの開発に携わるメンバーによる執筆で、機能を正しく理解して現場で活用できるノウハウが満載です。 目次 はじめに 読んでいただく際の留意事項 謝辞 目次 第1章：PostgreSQLの概要 リレーショナルデータベースとは データベースとは データモデル リレーショナルデータベースの役割 トランザクション管理 原子性（Atomicity） 一貫性（Consistency） 分離

EXPLAINを使ったPostgreSQLのクエリ最適化の基本と実践

PostgreSQL18連載の6本目の記事です。 PostgreSQL 18がリリースされました。リリースされた機能のうち私は「B-treeインデックスのスキップスキャン」機能が気になったので、機能の特徴を深堀りしつつ、実際の挙動を確認してみます。 B-treeインデックスのスキップスキャンとは複合インデックス（複数の列で構成されるインデックス）の利用効率を劇的に向上させる新しいスキャン方法です。 従来の課題PostgreSQLでは、例えば(列A, 列B)という順番で複合インデックスを作成した場合、これまではWHERE句に先頭の「列A」の条件がないと、インデックスを効率的に使えませんでした。 例えば、WHERE 列B = 'hoge'というクエリでは、せっかくの (列A, 列B) インデックスをうまく使えず、結果としてテーブル全体をスキャン（シーケンシャルスキャン）してしまう、あるいは、イ

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

Amazon Web Services ブログ PostgreSQL パフォーマンス向上 : ロックマネージャー競合の診断と対策 (この記事は、Improve PostgreSQL performance: Diagnose and mitigate lock manager contention を翻訳したものです。) ワークロードが拡張するにつれて、データベースの読み取り操作が予期せず遅くなっていませんか？PostgreSQL ベースのシステムを運用している多くの組織では、すぐには明らかにならないパフォーマンスのボトルネックに遭遇する事があります。多数のパーティションやインデックスを持つテーブルに対して多くの同時読み取り操作がアクセスすると、PostgreSQL の高速パスロック機能を使い果たし、システムが共有メモリロックを使用せざるを得なくなることがあります。高速パスから共有メモリロ

PostgreSQL開発チームは先月（2025年5月）にリリースした「PostgreSQL 18 Beta 1」で非同期I/O処理を実装したことを明らかにしています。 同チームのテストによると、シーケンシャルスキャンやビットマップヒープスキャン、バキュームといった処理において2～3倍の性能向上が見られたとのことです。 同期処理はシンプルだが待ち時間が発生する これまでのPostgreSQLは同期I/O処理を採用していました。これは例えばOSにファイルリードのようなI/O処理を依頼すると、処理が終了して結果が返ってくるまで、すべてのPostgreSQLの内部処理が一時停止することを意味します。 同期I/O処理の利点はすべてのI/O処理が同期的に行われるため、実装が比較的シンプルで容易だというメリットがあります。これはバグを引き起こしにくいとも言えます。 一方で、ひとつひとつのI/O処理が完了

はじめにフューチャー社内の有志メンバーでPostgreSQL DB設計ガイドラインを作成しました。 PostgreSQL設計ガイドライン | Future Enterprise Arch Guidelines 形になってから数ヶ月寝かせており、ある程度社内の指摘を取り込むことができたのでこのタイミングで告知します よくあるDB設計規約との差別化ポイント単にDB設計ガイドラインというと何を今更？感もあるので、命名規則や型桁など一般的な内容に加え、以下の点でよくあるDB設計ガイドラインから一歩踏み込んだコンテンツとなるよう心がけました。 論理設計への踏み込み単なるテーブル定義やデータ型選択にとどまらず、より高度な論理設計の原則に焦点を当てています。 マスタ/トラン/ワークデータベース設計において、データの種類に応じてテーブルを明確に分離することは設計効率と保守性を高める上で重要ですが、意外とそ

3行まとめ PostgreSQLのRLSはテーブル定義と共にポリシー定義をする必要があるが、別に定義する必要があるので忘れがち 人間が気をつけるのは不可能なので仕組みで解決するべくリンターを作った Cline + Claude 3.7 sonnetですぐ作れたけど楽しくなかった GitHub - Azuki-bar/postgrls: PostgreSQL RLS linter 背景 PostgreSQLのRow Level Security(以下RLS)を使ったことがありますか。 PostgreSQLではテーブル定義と共にAlter TableをしてRLSを有効にする必要があります。しかもこれだけではまだ不十分でそこからポリシーを有効にする必要があります。 -- https://www.postgresql.jp/document/16/html/ddl-rowsecurity.html

PostgreSQL 17.3, 16.7, 15.11, 14.16, 13.19 がリリースされました (2025-02-13) 2025年2月13日、PostgreSQL 17.3, 16.7, 15.11, 14.16, 13.19 がリリースされました。 セキュリティ修正を含むバグ修正のマイナーリリースとなります。 以下のセキュリティ修正が含まれます。 libpq の PQescapeString と関連する関数が無効なエンコーディングの入力文字列に対して頑強になりました。13.x から 17.x のマイナーバージョン系列で該当します。特に直接サーバに送るSQL文に使う以外の用途のときに危険がありました。 (CVE-2025-1094) また、17.x むけには、以下の非互換を伴う変更が含まれます。 接続要求での 64バイト以上の長いデータベース名とユーザ名の自動切り捨てが 16

質問されることが多いのでPostgreSQL初学者が運用を行うためにしっておく知識に必要な内容をまとめる。 PostgreSQLの基本的なアーキテクチャ PostgreSQLのアーキテクチャを知らないと自分がやっている作業が危険な作業かどうかわからないし、パラメータの意味もわからない。 そこで以下のリンクを読むと良い。 富士通が後述の資料を参考にまとめたのだろうなと思われる記事。 非常によくまとまっているのでわかりやすい。 www.fujitsu.com もっと細かく知りたいならPostgreSQL Internalsがおすすめ。 富士通の資料と重複するところがあるがこっちが本家。 Githubで管理されているので誤字脱字などあったら気軽にPRを出してほしい。 www.postgresqlinternals.org PostgreSQL Internalsが少し古いので最新事情で知りたい場

中国地方DB勉強会 in 岡山の登壇資料です。 そのうちここで登壇動画が公開されることでしょう。 肝心なチートシートは以下のとおり。 PostgreSQL gist.github.com MySQL gist.github.com チートシートだけじゃわからない！困ってる！ Have Fun Techがバージョンアップのサポートしますのでお気軽にご相談ください。 have-fun.tech まとめ やっぱ中国地方DB勉強会は最高だぜ！

今回の記事は、パフォーマンスチューニングの観点と仕組みを理解することに主眼を置いています。具体的な対処方法についてはシステムによって異なるため、マニュアルの確認や、各種チューニングサービスのご利用をご検討ください。なお、この記事で対象にしているPostgreSQLのバージョンは9.5以降です。 本記事の構成 本記事「パフォーマンスチューニング9つの技」は以下4つの記事から構成されています。他の記事も併せてご覧ください。 パフォーマンスチューニング9つの技 ～はじめに～ パフォーマンスチューニング9つの技 ～「書き」について～（本記事） パフォーマンスチューニング9つの技 ～「探し」について～ パフォーマンスチューニング9つの技 ～「基盤」について～ 1. パフォーマンスチューニングの「書き」とは 一般的にデータベースは、大量データを扱い、大量の問い合わせや更新を高速に処理し、さらに障害発生

AWSは、追加料金なしでAmazon RDS for PostgreSQLの性能を最大2倍に引き上げる「Amazon RDS Optimized Reads」のAmazon RDS for PostgreSQL対応を発表しました。 Amazon RDS Optimized Readsによる高速化の仕組み Amazon RDSは、データベースを格納するストレージとしてネットワーク上のElastic Block Storage（EBS）を利用しています。 今回リリースされたAmazon RDS Optimized Readsは、PostgreSQLがデータベース処理の際に生成する一時テーブルを、EBSの代わりにローカルのNVMeベースのSSDブロックレベルストレージに配置することで、ネットワーク上のEBSへのトラフィックを削減し、一時テーブルの処理を高速化、これによりクエリの高速処理を実現して