カフカは速い – ポストグレスを使います

2025年10月29日原文(topicpartition.io)

概要

技術界隈には「バズワード追求派」と「常識重視派」の2つの陣営が存在
最近は「Small Data」ムーブメントと「Postgresルネサンス」が常識派を後押し
Postgresは多くの用途でシンプルかつ十分な性能を発揮
Kafkaのような高度な分散システムが不要なケースが多い現実
本記事ではPostgresのpub/sub・キュー用途でのスケーラビリティをベンチマーク

技術界隈の2つの陣営

バズワード追求派 ：流行りの技術やキーワード（例：real-time, cloud-native, AI-powered）を深く考えずに採用
履歴書駆動設計 （Resume-driven design）の蔓延
コンサルタントやシステム設計面接 が「Googleスケール」な技術選定を推奨
キャリア評価 も「最新スタック」へのリプレースが重視される傾向
常識重視派 ：本質的な要件から技術選定を行い、複雑化や過剰設計を避ける
ベンダーの主張やマーケティング に懐疑的な姿勢
シンプルで堅牢な設計 を優先

PostgresとKafkaの比較

Postgres ：シンプル、スケーラブル、信頼性高、長年の実績
Kafka ：より大規模なスケール対応、堅牢なpub/sub基盤
小規模〜中規模用途ではPostgresで十分 なケースが多い
「最適な技術選択」は技術的観点だけでなく実用性重視が重要

本記事の目的

Postgresのpub/sub用途でのスケール限界のベンチマーク
Postgresのキュー用途でのスケール限界のベンチマーク
どんな場合にPostgresが適しているかの考察
詳細な技術評価や網羅的な検証ではなく、実用的なデータポイント提示が目的

ベンチマーク結果（要約）

Pub/Sub
- シングルノードc7i.xlarge：書込4.8MiB/s、読込24.6MiB/s、最大60msレイテンシ
- 3ノードレプリケーション：書込4.9MiB/s、読込24.5MiB/s、最大186msレイテンシ
- シングルノードc7i.24xlarge：書込238MiB/s、読込1.16GiB/s、最大853msレイテンシ
Queue
- シングルノードc7i.xlarge：合計2.81MiB/s、最大17.7msレイテンシ
- 3ノードレプリケーション：合計2.34MiB/s、最大920msレイテンシ（レプリケーション遅延）
- シングルノードc7i.24xlarge：合計19.7MiB/s、最大930msレイテンシ

Postgresのpub/sub・キュー構成

Queue ：ポイント・ツー・ポイント通信、1回消費で即削除、厳密な順序保証なし
Pub/Sub ：1対多通信、ディスク保存で読者と書込を分離、厳密な順序保証あり
Kafka ：Log構造を用いた標準的pub/subシステム、Postgresで再現可能

実装概要

書込
- 各トピックパーティションごとに専用テーブル
- log_counterテーブル でオフセット管理
- バッチ書込+オフセット更新 をトランザクションで一括実行
読込
- consumer_offsetsテーブル で各コンシューマグループの進捗管理
- トランザクション内でバッチ取得＋オフセット更新
- Kafka同様のat-least-once/at-most-once処理
NOTIFY/LISTEN は最適化用途で完全な信頼不可、基本はポーリング設計

結論・考察

Postgresは多くのpub/sub・キュー用途で十分な性能
Kafkaのような分散システムは本当に必要な場合のみ選択
技術選定は「実用性」「シンプルさ」「運用容易性」を重視
小規模・中規模用途ではPostgresの活用が合理的

参考文献・関連リンク

GitHub: stanislavkozlovski/pg-queue-pubsub-benchmark
PG as Queue ブログ（Adriano著, 2023年）

Hackerたちの意見

めっちゃ共感するわ（笑）。データエンジニアリングやってるけど、最初の段落はいつも自分のことみたい。かっこいい技術がたくさんあるけど（時系列データベース、ベクトルデータベース、AzureのSynapseとか「レイクハウス」とか）、ほとんどは特別なケース用なんだよね。無駄だとは言わないけど、そういうのが転がってるのを見ると、実際のエンジニアリングの必要性よりも「雰囲気」で置かれた可能性が高い。PostgresはOpenAIにとって十分だし、君にも十分だと思うよ。

Postgresを何にでも使うアプローチには注意が必要だよ。テーブルや行のロックの仕組みや、保証されるシリアル化レベルは多くの人にはすぐには分からないし、パフォーマンスに敏感なワークロードには深刻なボトルネックになることもある。自分は数十年の間、Postgresを使ってきて幸せだよ。Postgresはたくさんのことができる！でも、何事も格言に頼りすぎない方がいいよ。

└

確かに、Postgresのパフォーマンスは大きな問題になりうるね。特にトラフィックが急増したときに、垂直スケーリングが厄介になることもある。Kafkaに使うのは、Kafkaの素晴らしい使い方の一つであるトラフィックバーストへの対処を誤解していることになる。突然、Postgresサーバーが圧倒されちゃって、Kafkaサーバーは問題ないのに。

└

自分の戦略は、まずPostgresを使うこと。アイデアを形にして、Postgresがボトルネックになったら切り替える。それが多くの場合、ボトルネックにならないんだよね。

└

誰かが「Postgresを使えばいい」と言ったとき、その人はデータとキューで同じインスタンスを使ってるのかな？

└

100% Postgresは永続的な置き換えを保証するものではないよ。もっと柔軟性があって、初めから速度も上がるシンプルなスタックの出発点としてよく使われる。Postgresから始めることでボトルネックが見えてきて、そこから最適化できるんだ。Postgresを調整するか、リソースを見直すか、Kafkaに飛び込むことも考えてみて。

└

これはどんなデータストレージにも当てはまるよ。並行性モデルや前提条件を理解して、ボトルネックがどこで発生するかを知っておく必要がある。リレーショナルデータベースの中でも、かなりの違いがあるからね。

自分にとってKafkaのキラーフィーチャーは、各コンシューマーごとにオフセットを独立して設定できることだった。うちの会社では、ほとんどのトピックを複数のアプリケーションやチームが消費する必要があるから、この機能は必須なんだ。オフセットをプログラム的に前後に動かせる能力も、何度も助けられたよ。Postgresはキューに対してこの機能をサポートしてるの？

└

各コンシューマが自分のオフセットを使うだけの話じゃない？キューのテーブルが順番通りか時間でインデックス付けされてれば、コンシューマは小さい/早いキーを提供するだけでオフセットを達成できるんじゃないかな？（何か見落としてる？）

└

記事は基本的に、大量のスループットが必要ないなら、Kafkaは多分必要ないって言ってるね。（私の解釈では）オフセットも必要ないかもしれないし、マルチスレッドのサポートも必要ないから、複数のスレッドも必要ないってことだと思う。PGがキュー管理にどんなネイティブサポートを持ってるかはわからないけど、基本的に「見たらタスクを殺す」ってのが十分だって前提がある。スクリプトを書くことと実行することのシンプルさは、Kafkaの開発、インフラ、DevOpsコストをはるかに上回るよ。でも、15秒で何かをする必要があるのか、5分でいいのか、1時間でいいのかはビジネスの判断だし、持ってるワークロードの成長パターンを理解することも大事だよね。

少なくとも、Postgresの上にかなり厚いアプリケーションレイヤーが必要になると思う。それだと、結局別のメッセージングシステムを作っただけになりそう。みんながその一つのテーブルを使うことに同意するような小さなチームじゃない限り、トランザクションの管理やcronジョブの保持、YOLOクラスタリングとかちゃんとやらないとね。パフォーマンスは、PostgresよりKafkaを選ぶ理由の中で多分最後の方だと思うよ。

└

APIをPostgresで公開するのは、他の開発者たちが使っているのと同じようにやればいいよ。それで終わり。キューの実装はいくつかあって、目的を達成する確率を上げることができるよ。https://github.com/dhamaniasad/awesome-postgres

Hacker Newsで議論の続きを見る

ハクソク