필사 모드: いま注目のオープンソース (3) インフラとデータベース

• はじめに — この勢力図はライセンスが描き直した
• スナップショット
• 分析 — データを動かさずに問い合わせる
• Postgresを拡張する
• 組み込みとキャッシュ
• プラットフォームとIaC
• 導入前の確認
• リンク

はじめに — この勢力図はライセンスが描き直した

インフラとデータベースの領域がこの数年で経験した変化は、技術よりもライセンスから来ました。広く使われていたプロジェクトが商業利用を制限するライセンスへ移り、そのたびにコミュニティはフォークで応えてきました。

そのためこの分野では、性能比較よりライセンス確認が先というケースが多くあります。以下のリストは順位ではなく、解決する問題ごとにまとめた地図です。

スナップショット

すべて2026-08-12時点の値です。

分析 — データを動かさずに問い合わせる

duckdb/duckdb はプロセスの中で動く分析用データベースです。サーバーがないので、PythonのノートブックやCIのジョブからParquetファイルをそのまま問い合わせできます。以前ならクラスタに載せていた規模の集計が、ノートPCで終わってしまうケースが増えました。逆に、複数のユーザーが同時に使う共用ウェアハウスの座を狙った代物ではありません。

-- 例: リモートのParquetファイルをロードなしでそのまま集計する
SELECT country, count(*) AS n
FROM read_parquet('s3://bucket/events/*.parquet')
GROUP BY country
ORDER BY n DESC
LIMIT 10;

ClickHouse/ClickHouse は逆に、大規模な分析クエリを常時受け付けるサーバーです。カラム型ストレージとベクトル化実行によって、大きなテーブルの集計を高速に処理します。更新と削除が頻繁なワークロードや、複数テーブルの結合が中心となる設計にはあまり向きません。

risingwavelabs/risingwave は、ストリーム処理の結果をテーブルのように維持するデータベースです。SQLでリアルタイム集計を定義したいときに候補になります。状態を持ち続けなければならない構造なので、運用の難度はバッチより高くなります。

Postgresを拡張する

pgvector/pgvector はPostgresにベクトル型と類似度検索インデックスを追加します。データがすでにPostgresにあるなら、別途ベクトルデータベースを導入する前にまず試してみる選択肢です。ライセンスはGitHubが自動分類できませんが、LICENSEファイルを開いてみると、Postgres本体と同じ系統の寛容なライセンス文言を含んでいます。

cloudnative-pg/cloudnative-pg は、Kubernetes上でPostgresクラスタを運用するオペレーターです。フェイルオーバーやバックアップの手順を宣言的に扱います。ただしマネージドデータベースから移ってくると、それまでクラウド事業者が代わりに担っていた運用責任がチームへ移ってきます。

electric-sql/pglite はPostgresをWebAssemblyにビルドし、ブラウザやNodeの中で動かします。テストやローカルファーストのアプリケーションに使えます。リポジトリが2024年2月にできた若いプロジェクトなので、拡張のサポート範囲と限界をまず確認してください。

組み込みとキャッシュ

tursodatabase/libsql はSQLiteから分かれて、レプリケーションとサーバーモードを追加したプロジェクトです。エッジ環境で読み取りを近くに置こうとする設計に合います。

valkey-io/valkey はRedisのライセンス変更後に作られたフォークで、BSD 3条項を維持しています。リポジトリは2024年3月にできましたが、コードベース自体は長く検証されてきた系譜を引き継いでいます。ライセンス条件のために代替を探している状況なら、最も直接的な候補です。

nats-io/nats-server はメッセージングとストリーミングを担当します。2012年に始まり長く運用されてきたプロジェクトで、Kafkaより軽い構成でリクエストとレスポンス、パブリッシュとサブスクライブをまとめて扱いたいときに候補になります。長期保存と大規模な再処理が中心であれば、性格が異なります。

プラットフォームとIaC

siderolabs/talos はKubernetesノード専用に設計されたLinuxディストリビューションです。SSHとシェルをなくしAPIだけで管理させることで、攻撃面を減らします。慣れたやり方でサーバーに入って直す運用を維持したいなら、向いていません。

opentofu/opentofu はTerraformのライセンス変更後に分かれて生まれたIaCツールで、MPL-2.0を維持しています。既存の構成資産はそのままで、ライセンスだけが問題という場合に実質的な選択肢になります。ただし商用の追加機能とプロバイダーエコシステムの細部は分かれ続けているので、使っているモジュールが両方で動くかどうかを確認する必要があります。

導入前の確認

ライセンス全文を自分で確認し、商業的な導入は法務レビューを通してください。この記事は法律アドバイスではありません。

この領域では、ライセンスが変わった前例が実際にあるという点が重要です。いま寛容なライセンスであるという事実は、これからもそうであるという保証ではありません。データベースを選ぶときは出ていくときのコストも一緒に見てください。データを標準形式で取り出せるか、プロトコルに互換性があるか、移行経路がドキュメントとして存在するかが、ライセンスのリスクを実際に減らしてくれます。

リポジトリ情報（スター数・ライセンス・最近の活動）は2026-08-12にGitHubで直接確認した時点の値です。数値と状態は変わります。

リンク

シリーズ: 前の記事 — ビルド・エディタ・CLI・ターミナル · 次の記事 — 可観測性とセキュリティ

このブログの関連記事:

• DuckDBの内部構造を深く見る
• OpenTofuとTerraformの比較
• SQLiteルネサンスと組み込みレプリカ
• PostgreSQLの内部構造とpgvector

ツール: SQLプレイグラウンド