オブジェクトストレージの上に「耐久性のあるストリーム」を作る PicoMQ──パーティションではなくストリームを量産する設計

3行まとめ

1. PicoMQは、S3互換オブジェクトストレージの上に構築された、HTTP経由の耐久性あるリアルタイムストリームエンジン。Rust製、Apache 2.0で公開。
2. 「1つのトピック内でパーティションを分ける」のではなく「ユースケースごとに独立したストリームを作る」設計思想を掲げ、各ストリームは個別にアドレス指定でき、アイドルから高スループットまでスケールするとしている。
3. コアはライブラリ（s3stream）とホスト（picomq）に分かれ、picoというCLIでストリームの作成・追記・読み取り・tail・ベンチマークまで一通り操作できる。

「パーティションではなくストリーム」という設計思想

公式サイトのトップに掲げられているのは「Durable streams on object storage」という一文だ。PicoMQはS3互換のオブジェクトストレージを土台に、HTTP経由の耐久性あるリアルタイムストリームを提供する。従来型のメッセージキューはよく「1つのトピックの中でパーティションを分けて並列度を稼ぐ」設計を取るが、PicoMQのアーキテクチャ説明ページでは「あらゆる種類のレコードを1つのトピックに詰め込むのではなく、ユースケースごとにストリームを作る」ことを勧めている。各ストリームは独立してアドレス指定でき、アイドル状態から高スループットまでスケールする、と説明されている。

CLIで触れる操作

GitHubリポジトリのREADMEを確認すると、リポジトリは2つの主要なディレクトリに分かれている。s3stream/はストリームエンジン本体（ライブラリであってサーバーではなく、WAL・オブジェクトレイアウト・キャッシュ・コンパクションを担う）、picomq/はホスト（メタデータプレーン・サーバー・HTTPフロントエンド・クライアント・pico CLI）だ。

インストールはcargo install --path picomq/pico-cli。単一ノードの起動例は次の通りで、メタデータをSQLite、オブジェクトストレージをローカルファイルシステムに向けている。

pico serve \
    --meta-url sqlite:./data/meta.db \
    --storage=-2@file://./objects

各フラグにはPICO_*という環境変数版が用意されており、/health・/readyは管理用リスン（デフォルト127.0.0.1:9090）上で提供される。認証はデフォルトでオフだが、ループバック以外にバインドする場合は--auth requiredか、明示的に--insecure-allow-remoteを指定する必要があるとREADMEにある。

ストリームの操作コマンドは次のように示されている。

pico create /streams/orders --content-type text/plain
seq 1 1000 | pico append /streams/orders --batch 100
pico read /streams/orders
pico tail /streams/orders -f
pico close /streams/orders && pico delete /streams/orders

pico --http2 bench -b 1024 -w 512 --connections 4 --streams 4 -d 60

作成・追記（バッチ対応）・読み取り・tail -fによるフォロー・クローズ・削除、そしてHTTP/2でのベンチマークコマンドまで一通り揃っている。

Dockerでの起動パターンは3種類

READMEにはharness/aioディレクトリを使ったDocker Compose構成が3種類用意されている。Postgres＋RustFSの単一ノード構成、同じスタックの2ノードクラスタ構成（compose.cluster.yml）、そして依存ゼロのSQLite＋ローカルファイル構成（compose.lite.yml）だ。Picoはhttp://localhost:4437（クラスタ構成では:4438も）でリッスンし、ダッシュボードは:9090で提供される。既存のPostgresやオブジェクトストアと組み合わせる場合はharness/byoが.env経由での接続に対応する。

エンジン内部の階層構造

ストリームエンジンs3streamのREADMEも別途確認した。ライブラリとしての階層は次のように説明されている。

s3stream (facade: Config, builder)
  └── s3stream-core   (S3Storage pipeline, cache, compaction)
        ├── s3stream-wal     (object WAL, memory WAL)
        └── s3stream-object  (object format, ObjectStorage over object_store)
              └── s3stream-codec  (record codec, WAL framing, CRC)

ホスト側はStreamManager/ObjectManagerというトレイトを通じてストリームとオブジェクトのメタデータを提供する構造になっている。ワイヤーフォーマットはspecification/ディレクトリに、互換性を担保するゴールデンフィクスチャはconformance/にある、とREADMEに記載されている。

中身はゼロから書かれたわけではない──AutoMQ由来のエンジン

リポジトリ直下のNOTICEファイルを確認すると、重要な事実が書かれている。

This product includes software derived from AutoMQ S3Stream (https://github.com/AutoMQ/automq). Copyright 2023-2025, AutoMQ HK Limited. Licensed under the Apache License, Version 2.0.

（本製品には、AutoMQ S3Streamに由来するソフトウェアが含まれる。著作権は2023-2025年、AutoMQ HK Limitedに帰属。Apache License 2.0の下でライセンスされている）

つまり、PicoMQの中核であるストリームエンジンs3streamは完全新規実装ではなく、Kafka互換のクラウドネイティブストリーミング基盤として知られるAutoMQのS3Stream実装を土台にしている。WAL・オブジェクトレイアウト・キャッシュ・コンパクションといった、記事内で先に触れた階層構造の設計思想がAutoMQと近いのは、この由来を踏まえると説明がつく。両者ともApache 2.0ライセンスで、NOTICEファイルによる帰属表示が守られている。

Kafkaクライアントからも接続できる作り

ルートのCargo.toml（ワークスペース定義）を見ると、picomq/pico-kafkaという名前のクレートがワークスペースメンバーに含まれている。このクレート自身のCargo.tomlにはdescription = "Kafka wire-protocol frontend for PicoMQ"（PicoMQ向けのKafkaワイヤープロトコル・フロントエンド）と明記されており、kafka-protocolクレート（broker/client機能、gzip・zstd・snappy・lz4の圧縮対応）に依存している。README本文では触れられていなかったが、既存のKafkaクライアントライブラリからPicoMQに接続できるようにする経路が、少なくともコード上は用意されていることが分かる。

ワークスペース全体は16個のcrateに分かれており、バージョンは0.1.0（Rust edition 2021）。GitHub APIで見るリポジトリの規模は、Star 289・Fork 3・Open issues 6で、作成日は2026年8月11日と、本記事執筆時点でまだ3週間に満たない新しいプロジェクトだった。

ワークスペースの内訳（Cargo.tomlより）

開発の背景（企業か個人か）は特定できなかった

本記事はPicoMQの公式サイト（picomq.com）とGitHubリポジトリのREADME（picomq/picomq本体およびs3streamサブディレクトリ）、GitHub APIのリポジトリメタデータ、NOTICEファイル、ルートおよびpico-kafkaのCargo.tomlを2026年8月27〜30日にcurlで取得した内容にもとづく。公式サイトのトップページ自体はドキュメント部分がJavaScript必須のSPAで、詳細な仕様まではGitHub側のREADMEから補っている。筆者の手元でDocker Composeを起動し、ベンチマークコマンドを実行して性能を計測したわけではなく、pico-kafkaが実際にKafkaクライアントから接続できることを自分で確かめたわけでもない（クレートの依存関係と説明文から機能の存在を確認したのみ）。開発の背景（企業か個人プロジェクトか）についても、サイト・READMEいずれにも明記が見当たらなかった。GitHub API経由でOrganizationの情報を見ると、コントリビューターとして確認できたのはaddu390という1アカウントのみで、同じOrganizationにはPostgresとApache Iceberg間のデータ階層化ツール「tierdb」という別リポジトリもあった。ここから「小規模チームまたは個人による開発である可能性」は推測できるが、運営主体が企業かどうかを断定できる記述はどこにもなかった。

オブジェクトストレージ上のストリーム基盤という話題は未紹介

Zenn・Qiitaともに言及はゼロだった。メッセージキュー・ストリーミング基盤の比較記事は日本語圏にも多いが、「オブジェクトストレージの上に構築された耐久性あるストリーム」という設計、および「パーティションではなくストリームを量産する」という思想はまだ紹介されていない。

関連記事

• RAG（検索拡張生成）とは？仕組みと導入方法【2026年解説】
• オープンウェイトとは何か──「オープンソース」との違いを一次資料で読み解く