PostgreSQL 18の新機能「B-treeインデックスのスキップスキャン」 | フューチャー技術ブログ
PostgreSQL18連載の6本目の記事です。 PostgreSQL 18がリリースされました。リリースされた機能のうち私は「B-treeインデックスのスキップスキャン」機能が気になったので、機能の特徴を深堀りしつつ、実際の挙動を確認してみます。 B-treeインデックスのスキップスキャンとは複合インデックス（複数の列で構成されるインデックス）の利用効率を劇的に向上させる新しいスキャン方法です。 従来の課題PostgreSQLでは、例えば(列A, 列B)という順番で複合インデックスを作成した場合、これまではWHERE句に先頭の「列A」の条件がないと、インデックスを効率的に使えませんでした。 例えば、WHERE 列B = 'hoge'というクエリでは、せっかくの (列A, 列B) インデックスをうまく使えず、結果としてテーブル全体をスキャン（シーケンシャルスキャン）してしまう、あるいは、イ
Announcing Pg_duckdb Version 1.0 - MotherDuck Blog
We're excited to share the 1.0 release of pg_duckdb, an open-source PostgreSQL extension that brings DuckDB's vectorized analytical engine directly inside PostgreSQL. You can think of it as adding a turbo engine to your PostgreSQL database–ready to run efficient, ad hoc queries while PostgreSQL continues doing what it does best: transactional workloads for your production app. Pg_duckdb embeds a D
PostgreSQL パフォーマンス向上 : ロックマネージャー競合の診断と対策 | Amazon Web Services
Amazon Web Services ブログ PostgreSQL パフォーマンス向上 : ロックマネージャー競合の診断と対策 (この記事は、Improve PostgreSQL performance: Diagnose and mitigate lock manager contention を翻訳したものです。) ワークロードが拡張するにつれて、データベースの読み取り操作が予期せず遅くなっていませんか？PostgreSQL ベースのシステムを運用している多くの組織では、すぐには明らかにならないパフォーマンスのボトルネックに遭遇する事があります。多数のパーティションやインデックスを持つテーブルに対して多くの同時読み取り操作がアクセスすると、PostgreSQL の高速パスロック機能を使い果たし、システムが共有メモリロックを使用せざるを得なくなることがあります。高速パスから共有メモリロ
新興 PostgreSQL サービス企業の買収劇の背景：Snowflake と Databricks が描く未来に思いを馳せてみた
新興 PostgreSQL サービス企業の買収劇の背景：Snowflake と Databricks が描く未来に思いを馳せてみた 日本の PostgreSQL コミュニティが今月、大きな盛り上がりを見せています。その理由は、データ・AI 業界の二大巨頭である Snowflake と Databricks が、立て続けに PostgreSQL のマネージドサービスプロバイダの新興企業を買収し、両社が PostgreSQL のマネージドサービス提供を開始すると発表したためです。この動きは、 PostgreSQL がこれまで以上に最も重要なデータベースの一つとしての地位を確立し、PostgreSQL ユーザーのスキルが活かせる場が大きく広がっていることを示唆しています。 なぜ、この買収劇が立て続けに起きたのでしょうか。考えられる主な理由は以下の 3 点です。 1. アナリティクスプラットフォー
次期PostgreSQL 18では非同期I/Oの採用により性能が2～3倍向上する見通し
PostgreSQL開発チームは先月（2025年5月）にリリースした「PostgreSQL 18 Beta 1」で非同期I/O処理を実装したことを明らかにしています。 同チームのテストによると、シーケンシャルスキャンやビットマップヒープスキャン、バキュームといった処理において2～3倍の性能向上が見られたとのことです。 同期処理はシンプルだが待ち時間が発生する これまでのPostgreSQLは同期I/O処理を採用していました。これは例えばOSにファイルリードのようなI/O処理を依頼すると、処理が終了して結果が返ってくるまで、すべてのPostgreSQLの内部処理が一時停止することを意味します。 同期I/O処理の利点はすべてのI/O処理が同期的に行われるため、実装が比較的シンプルで容易だというメリットがあります。これはバグを引き起こしにくいとも言えます。 一方で、ひとつひとつのI/O処理が完了
AWS、事実上無制限にスケールするPostgreSQL互換の大規模分散DB「Amazon Aurora DSQL」正式版を提供開始
Amazon Web Services（AWS）は、事実上無制限にスケールするPostgreSQL互換の大規模分散データベース「Amazon Aurora DSQL」の正式版を提供開始したと発表しました。 Amazon Aurora DSQLは昨年（2024年）12月のイベント「AWS re:Invent 2024」で発表された、サーバレスな大規模分散データベースです。 1つのリージョン内で3つのアベイラビリティゾーンにまたがる構成、もしくは複数のリージョンにまたがる構成において、自動スケーリングと自動障害復旧機能を備えたActive-Activeなクラスタを実現できます。 分散処理による高いスケーラビリティおよび複数のアベイラビリティゾーンやリージョンによる冗長構成による高可用性の両方を実現するだけでなく、複数リージョンのような広域での分散データベースにおいてトランザクション処理による強
PostgreSQL設計ガイドラインのご紹介 | フューチャー技術ブログ
はじめにフューチャー社内の有志メンバーでPostgreSQL DB設計ガイドラインを作成しました。 PostgreSQL設計ガイドライン | Future Enterprise Arch Guidelines 形になってから数ヶ月寝かせており、ある程度社内の指摘を取り込むことができたのでこのタイミングで告知します よくあるDB設計規約との差別化ポイント単にDB設計ガイドラインというと何を今更？感もあるので、命名規則や型桁など一般的な内容に加え、以下の点でよくあるDB設計ガイドラインから一歩踏み込んだコンテンツとなるよう心がけました。 論理設計への踏み込み単なるテーブル定義やデータ型選択にとどまらず、より高度な論理設計の原則に焦点を当てています。 マスタ/トラン/ワークデータベース設計において、データの種類に応じてテーブルを明確に分離することは設計効率と保守性を高める上で重要ですが、意外とそ
PostgreSQLをWebAssemblyとしてビルドした「PGlite」がPostgreSQL 17対応にバージョンアップ
PostgreSQLをWebAssemblyとしてビルドした「PGlite」がPostgreSQL 17対応にバージョンアップ PostgreSQLのソースコードをWebAssemblyバイナリとしてビルドしたことで、Node.jsなどのJavaScriptランタイムやWebブラウザ上でほぼフル機能のPostgreSQLを実行可能にした「PGlite」がバージョンアップして「PGlite 0.3」になり、PostgreSQL 17.4対応となりました。これまではPostgreSQL 16に対応していました。 PGliteはPostgreSQLのコードをWebAssembly化 PGliteはPostgreSQLのCのソースコードをEmscriptenコンパイラを用いてWebAssemblyバイナリとして出力、JavaScript/TypeScriptからライブラリとして呼び出せるようにした
Benchmarking PostgreSQL: The Hidden Cost of Over-Indexing
All of Percona’s open source software products, in one place, to download as much or as little as you need.
PGlite + pgvector で100行で実装するベクトル検索 (node/deno/drizzle)
pglite + pgvector で文章の類似度検索を実装します。 動機 とにかく手っ取り早くローカルにデータを突っ込んでおいて検索する RAG の雛形がほしかったんですが、調べても大規模ストレージを前提とした大掛かりな実装が多いです。 スクリプトを書いたらポンと実行できるセットアップ不要なものがあると、色々と実験ができます。 mastra/rag を読んでたら、簡単にできる気がしたのでやりました。ただ、chunk のドキュメント分割相当のものはまだ作ってません。そこまで難しい概念でもないので、雑に作れそうではあります。 qrdrant も検討しましたが、サーバーを建てるのが面倒でした 準備: ベクトル化用の関数 今回は @ai-sdk/openai を使ってベクトル化をします // OPENAI_API_KEY= import { openai } from "@ai-sdk/open
PostgreSQLはなぜMySQLを上回れた？ PostgreSQL 17で見えた生成AI時代のデータベース
世界トップに躍進したPostgreSQL データベース管理システム（DBMS）の世界で、大きな変化が起きている。長年、企業システムの中核を担ってきたのはMySQLだが、この数年でPostgreSQLがトップの座に躍進、またAI時代の到来により、そのポジションをさらに強固なものにしているのだ。 スタックオーバーフローが実施した開発者調査（2024年版）によると、PostgreSQLは2年連続でデータベースのトップに君臨、その利用率は51.9％に上る。これに対し、MySQLは39.4％にとどまり、両者の差は広がる一方となっている。 この数字の意味するところは大きい。わずか6年前の2018年、MySQLの利用率は59％を占めていたが、PostgreSQLは33％にすぎなかった。この劇的な逆転は、PostgreSQLの技術的優位性と時代のニーズが合致した結果といえる。 そもそもPostgreSQL
［速報］「Amazon Aurora DSQL」プレビュー公開、事実上無限にスケールする高性能なPostgreSQL互換の大規模分散データベース
Amazon Web Services（AWS）は、米ラスベガスで開催中のイベント「AWS re:Invent 2024」で、PostgreSQL互換の分散データベース「Amazon Aurora DSQL」のプレビュー公開を発表しました。 Amazon Aurora DSQLは、地理的に離れた複数のリージョンでデータベースが稼働する大規模分散データベースです。 分散処理による高いスケーラビリティ、複数のリージョンによる冗長構成による高可用性の両方を実現するだけでなく、分散データベースにおいてトランザクション処理による強い一貫性を実現する際の弱点とされていたレイテンシの大きさを克服し、小さなレイテンシによる高速性も兼ね備えたPostgreSQL互換のデータベースだと説明されています。 分散データベースの弱点はレイテンシの増大 一般に分散データベースは、複数のデータベースのノードが分散してリ
Amazon Aurora PostgreSQL がローカル書き込み転送のサポートを開始 - AWS
Amazon Aurora PostgreSQL 互換エディション では、Aurora リードレプリカからライターインスタンスに書き込みリクエストを転送できるようになりました。これにより、書き込み後の読み取りの整合性を必要とする読み取りワークロードのスケーリングが簡単になります。今回のリリースにより、Aurora MySQL と Aurora PostgreSQL の両方でローカル書き込み転送が利用できるようになりました。 書き込み転送を使用すると、アプリケーションが読み取りリクエストと書き込みリクエストの両方をリードレプリカに送信するだけで、Aurora が書き込みリクエストをクラスター内のライターインスタンスに転送します。これにより、読み取りと書き込みを分離する複雑なアプリケーションロジックを維持しなくても、アプリケーションで Aurora Replica の読み取りワークロードをスケ
主キーサイズの違いによるPostgreSQLの検索性能の違いを比較する - ドワンゴ教育サービス開発者ブログ
導入 実行環境 テーブル定義 レコード作成 テーブルサイズ 検索速度 結論 We are hiring! 導入 みなさん、RDBのテーブル設計はしていますでしょうか。 テーブル設計時の大きな関心事の1つとして、主キー設計があります。 主キー設計では、「自然キー vs サロゲートキー」や「連番 vs 乱数」が主題になることが多いですが、今回はカラムサイズに注目して、主キーのサイズが検索性能に与える影響について調査してみたいと思います。 インデックスを使った検索が高速であることはRDBの常識中の常識ですが、その時もディスクやメモリからインデックスの値を読み取ってCPUを使って比較を行う操作が発生するわけで、値のサイズが小さいことは理屈上ではCPUキャッシュの利用やその他IO処理などにおいて有利に働くはずです。 今回は主キーを指定した単体取得のクエリにおいて、その影響がどの程度なのかを実際に計測
【PostgreSQL】いかにして JSONB を安全に扱うか
はじめに Postgres には JSON/JSONB というデータ型がありますが，JSONB はデータをバイナリ形式で格納するためインサート時に変換のオーバーヘッドがあるものの，その後の処理が非常に高速である上に，インデックスを貼ることができるため，実用上は JSONB を使うのが一般的です． 一方で，そもそも RDB のようなスキーマの厳格な型付けをしているシステムで半構造化データである JSON を扱うこと自体がアンチパターンであるという指摘もあります． しかしながら，適切に設計，運用することで厳格な RDB で柔軟なデータを扱うことができ，アプリケーションの表現の幅を広げることができます． 本記事では，JSONB を可能な限り安全に扱うための実践的な工夫を紹介します． JSON Schema を使ったバリデーションを Check Constraint にする Postgres では
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - NickTikhonov/snap-ql: AI-powered Postgres Client
GitHub - wey-gu/py-pglite: PGlite wrapper in Python for testing. Test your app with Postgres just as lite as SQLite.
GitHub - vitabaks/autobase: Automated database platform for PostgreSQL® - Your own DBaaS.
Explain EXPLAIN
pg_flo - Stream, transform, and route PostgreSQL data in real-time
