Better Stack、ClickHouseとSQLで観測可能性を10倍安く組み直す

Better Stackはmonitoring、logging、incident management、status pageを統合するobservability platform。

ClickHouseとSQLを軸に、既存ツールの複雑さとコストを下げる。

公式発表では2022年時点で70,000人超の開発者、1,400社超が利用。出典

Juraj MasarとVeronika Kolejakは、以前の仕事でエンジニアが複数の古い運用ツールをつなぐ苦労を見ていた。

Better Stackの創業時の考えは、Juraj Masarの言葉で「We are simply engineers making the tools we always wanted to use」だった。出典

複雑なobservabilityへの違和感

2021年に始まったBetter Stackは、monitoring、logging、incident management、status pageを一つのプロダクトへ束ねた。

公式発表は、既存ツールが高価で、統合に手間がかかり、理解にも時間がかかることを問題として挙げている。出典

SQLを共通言語にする転換

Veronika Kolejakは、エンジニアの多くが各社固有のquery言語には不慣れでもSQLは知っていると説明した。

ClickHouseを使い、長くhot storageに置ける速度とコストを売りにした。出典

70,000人からAI SREへ

2022年時点で70,000人超の開発者と1,400社超が利用し、Series Aを含む調達は$18.6Mに達した。出典

現在はAI SRE、MCP server、eBPF、OpenTelemetryなどへ機能を広げている。出典

統合の次に残る問い

Better Stackの物語は、ツールを減らすことから、運用データをAIが扱える形にすることへ進んでいる。

読者にとっての示唆は、統合を目的にせず、query・価格・操作体験という具体的な摩擦を同時に解けるかを見ることだ。

開発チームはmonitoring、logs、incident response、status pageを別々に組み合わせる負担を抱える。

Better Stackはそれらを一つのUIにまとめ、SQLとClickHouseで既存observabilityの複雑さとコストを下げる。

公式発表では2022年時点で7万人超の開発者と1,400社超が利用していた。出典

ClickHouseを土台にしたコスト・速度の組み合わせと、monitoringからincident managementまでの統合データモデルが障壁になる。

ただし基盤技術そのものは模倣可能で、UXと蓄積データが重要だ。出典

ネットワーク効果は弱い。

顧客が増えても同じ製品の価値は直接増えず、導入事例と運用知識の蓄積による信頼効果が中心になる。出典

インフラ専任者を大きく置けないスタートアップから、複数サービスを運用する開発チームまで。

SQLに慣れたチームほど移行の学習コストが低い。出典

単なる機能追加ではなく、SQLをobservabilityの共通言語にした点が大きい。

ClickHouseによる高速・低コストなデータ処理と、Figma-likeなUIを同時に訴求している。出典

observability市場はDatadogやNew Relicが強く、既存のqueryや運用を移行するコストが残る。

AI SREは新しい機能領域で、誤検知や説明責任を含む検証が必要だ。出典

開発者向けのfree tier、docs、GitHub、コンテンツで導入障壁を下げ、monitoringからlogs・incident managementへ拡張する。

AI SREとMCPは既存データを新しい操作面へ変える追加導線だ。出典

主要チャネル: content, community, github, product-led

カテゴリの既存大手を正面から機能数で追うのではなく、価格、速度、UI、query言語のような複数の不満を一つの選択理由に束ねる。

統合は「何でも屋」ではなく、共通データモデルがあって初めて効く。

日本ではSaaS導入後の運用担当が限られる企業が多い。

日本語のincident templates、国内リージョン、SIer向けの導入支援を組み合わせれば、価格だけでなく運用標準化として提案できる。