5万
ClickHouse Managed Postgres は、ただのホスト型 Postgres ではありません。統合データスタックの半分です。その中身は、トランザクションワークロードを受ける NVMe ベースの Postgres、リアルタイム分析を担う ClickHouse、そして両者を同期し続けるフルマネージドのレプリケーションです。2系統のデータベースを、1つの製品として運用します。
私たちは、この組み合わせの価値をユーザー自身に体感してもらいたいと考えました。そこで自問しました。サインアップから、自分のデータで Postgres + ClickHouse スタック全体の価値を体感するまでの最短経路は何か?
この問いが、既存の体験の隙間を浮かび上がらせました。
Postgres サービスを作成すると、ユーザーには Overview ページが表示されていました。このページは稼働中のデータベースを前提に設計され、運用メトリクスやアクティビティを表示します。しかし使い始めたばかりの人にとっては、何もかもが空でした。アクティビティも、探索するデータもなく、次に何をすべきかの手がかりもほとんどありませんでした。
一方で、その道筋がどうあるべきかについては、ドキュメントにすでに確かな答えがありました。CLI のクイックスタートガイドは、Postgres のプロビジョニング、100万行のロード、CDC ClickPipe の設定、レプリケートされたテーブルへのクエリ実行(ClickHouse から、および pg_clickhouse 経由で Postgres から)という一連の流れを案内します。手順は正確でスクリプト化もでき、パワーユーザーにはこのガイドを案内しています。
しかし、ドキュメントのクイックスタートガイドは並走する別の線路です。ユーザーはあるタブで読みながら別のタブで作業し、製品側はユーザーが道筋のどこにいるのかを知りません。私たちは、この一連の道筋をそのまま ClickHouse Cloud の内側に置きたいと考えました。置くのは、状態を持ち、ユーザーがすでに何を済ませたかを把握し、価値を生む次の一歩を指し示せる仕組みです。
人はデータベースの価値をどう体感するのか
私たち ClickHouse はデータベースこそ最高のものだと考えていますが、ときに少し退屈になりうることも認めています。ClickHouse Cloud での経験から分かったのは、人はダッシュボードを眺めてではなく、データを扱うことでデータベースの価値を体感する、ということです。
そのため、Postgres にデータを入れることが自然な出発点になりました。そこからユーザーはクエリを実行して Postgres の手応えを確かめ、同じデータがいかに簡単に ClickHouse へ流れてリアルタイム分析に使えるかを見られます。これがオンボーディング体験の土台になりました。
製品の価値を4ステップで
統合データスタックを現実のものにする4ステップです。
| ステップ | ユーザーがすること | 証明する内容 |
|---|---|---|
| 1 | Postgres サービスを立ち上げる | 数分でプロビジョニングされる NVMe Postgres |
| 2 | データを移行または取り込む | ClickPipes によるフルマネージドの Postgres → Postgres 移行 |
| 3 | 最初のクエリを実行する | 自分のデータでの素のスループットを SQL Console で確認 |
| 4 | ClickHouse で分析を実行する | ClickHouse への CDC + 単一のクエリレイヤーとしての pg_clickhouse |
これらを終えれば、製品の中核の価値に触れたことになります。その先はすべて探索です。
ステップ1: Postgres サービスを立ち上げる
プロビジョニングは、あえて最も地味なステップにしてあります。サービスが正常に作成されたことを確認する段階です。クラウドサービスプロバイダーとリージョン、サイズ、Postgres のバージョンを選ぶと、数分でサービスが稼働します。ストレージには NVMe を使っており、性能の話はここから始まります。
数分後には、稼働中のデータベースがあり、設定すべきものは何も残っていません。
ステップ2: データを移行または取り込む
すべてのユーザーにぜひ完了してほしいのが、このステップです。データベースはデータが入ってはじめて面白くなります。
ほとんどの人は、既存の Postgres からの移行から始めるべきです。自分のテーブル、自分のクエリ、自分のアクセスパターンほど説得力のあるものはありません。
これが最も価値の大きいワークフローだと考えているため、「Migrate data from your Postgres database」(Postgres データベースからデータを移行する)をオンボーディング体験の主要な要素として前面に置きました。
ClickPipes は、この移行をフルマネージドの Postgres 間ワークフローとして処理します。ユーザーは接続文字列を渡すだけで、スナップショット、パブリケーション、レプリケーションスロット、継続的な同期は ClickPipes が引き受けます。
しかし、誰もが初日から既存のデータベースを接続できるわけではありません。まず製品を探索したいユーザーもいれば、手早く試す方法だけが欲しいユーザーもいます。そこで、データを投入する別の手段も用意しました。
- 言語クライアントで接続する: Postgres は Postgres です。手元にあるドライバをそのまま使えます。
- サンプルデータセットをロードする: 数秒でクエリを始められます。
- テーブルをゼロから作る: テーブルクリエイターで、すぐに手を動かして始められます。
まだデータベースを接続したくない場合は、いくつかのサンプルデータセットを利用できます。
ステップ3: 最初のクエリを実行する
データが入ったら、ユーザーに SQL Console を探させるのではなく、そのまま案内します。そこでテーブルを確認し、最初のクエリを実行できます。
ここで初めて本物の「なるほど!」が訪れます。ユーザーが設定作業を終え、製品を体験し始める地点です。
空のエディタから始めたくない場合は、やりたいことを伝えれば AI Assistant が SQL の生成を手伝います。データを移行した直後でスキーマにまだなじみがないときに特に役立ちます。
ステップ4: ClickHouse で分析を実行する
これは他のどのマネージド Postgres も提供できないステップです。統合スタック全体がここで一つにつながります。
数クリックで Postgres CDC ClickPipe を設定できます。既存の Postgres データをまず ClickHouse へコピーし、その後はすべての変更を継続的にレプリケートします。数分のうちにデータが ClickHouse へ流れ始め、両者のラグは1分未満です。運用ワークロード用のシステムと分析用のシステムが一つずつ揃い、パイプラインを自分で構築・維持することなく同期が保たれます。
Postgres のエコシステムに完全にとどまりたいチーム向けに、pg_clickhouse 拡張も案内しています。なじみのある PostgreSQL 構文で ClickHouse にクエリでき、両エンジンにまたがる単一のクエリレイヤーが得られます。
ClickHouse のテーブルを外部テーブルとしてインポートすると、Postgres が両エンジンにまたがる単一のクエリレイヤーになります。同じ接続、同じ SQL で、分析クエリは ClickHouse 側で実行されます。100万行のデータセットでも3〜7倍高速です。集計を5つ含むクエリは 555 ms から 164 ms に、集計を伴う JOIN は 1,246 ms から 170 ms に短縮されます。この差は規模が大きくなるほど広がります。
ステップ4を終えたときには、トランザクションの書き込み、マネージド CDC、分析の読み取りという統合スタック全体を、何も自分で組み立てずに一通り体験したことになります。
勢いを生む設計
新しいオンボーディングプロセスは、意図的に短く、見えやすく、成果志向に保ちました。ステップを一つ終えるごとに前へ進んでいる実感が増し、残りのステップを見ればゴールが手の届くところにあると分かります。
また、各ステップは UI 操作ではなく成果として記述することにしました。「SQL Console を開く」「CDC を設定する」と指示する代わりに、達成してほしいことに焦点を当てています。
- Postgres サービスを立ち上げる
- データを移行または取り込む
- 最初のクエリを実行する
- ClickHouse で分析を実行する
あえて4ステップで止めました。もっと入れたくなりましたが、オンボーディングはドキュメントではありません。その役割はすべての機能を教えることではなく、ユーザーが製品の価値を理解し、自力で探索を続けられるところまで製品の中へ導くことです。
ClickHouse Managed Postgres で私たちが目指すのは、高速で信頼できる Postgres 体験を提供し、その数ステップ先に ClickHouse の分析の力を置くことです。新しいオンボーディング体験は、そこへより早くたどり着けるよう設計しています。ぜひお試しいただき、フィードバックやアイデアをお聞かせください。
