フェデレーション

1 つの場所から複数ワークスペースをまたいでクエリ — Max プラン以上。

更新 2026-04-17

ほとんどのチームは単一ワークスペースを運用します。チーム、クライアント、または環境で分けて複数になると、質問がそれらをまたぐようになります。フェデレーションがその答えです。

フェデレーションを使うと、複数ワークスペースのデータを必要とする質問をして、1 つの統一された答えを得られます。手動エクスポートも、ツール間 JOIN も不要。

いつ使うか

  • コンサルティング会社 が複数クライアントワークスペースを管理 — 「今月、全クライアントの保持率はどう？」
  • マルチブランド企業 がブランドごとに別ワークスペース — 「最も成長の早い有料チャネルを持つブランドは？」
  • マルチ環境セットアップ — 本番 vs ステージング vs サンドボックス — 「ステージングは本番と同じサインアップパターン？」
  • 分散チーム で各地域が自分のワークスペースを所有 — 「EU vs US の運用メトリクスを比較」。

ワークスペースが 1 つしかなければ、このページはスキップしてください。

仕組み

ワークスペースのうちの 1 つをフェデレーションルートとして宣言。ルートは承認した他のワークスペースへ（デフォルトで読み取り専用の）アクセスを得ます。ルートワークスペースで質問すると:

  • Agent がどのテーブルがフェデレート（他ワークスペース）でどれがローカルかを識別。
  • ワークスペースごとに別々のクエリを並列発行。
  • ルートワークスペースで結果を JOIN / UNION。
  • 1 つの答えを返します。

あなたの席からは 1 つのワークスペースに感じられます。裏では、各クエリは依然としてソースワークスペースの DB 内で実行されます — クロスデータベース行レプリケーションはありません。

セットアップ

すべて Max プラン以上で。ルートワークスペースで:

  1. Settings → Federation → + Add workspace。
  2. ターゲットワークスペースの ID を入力（ターゲットの Settings → About から）。
  3. ターゲットワークスペースの Owner にフェデレーションリクエストが届きます。承認 + 共有内容を選択:
    • すべて — 全テーブル。
    • 特定スキーマ — 例: public.* のみ、integrations.* は除外。
    • 特定テーブル — 細粒度リスト。
    • 読み取り専用（デフォルト）vs 読み書き（まれ。注意して使用）。
  4. 承認済み。フェデレートされたテーブルがルートワークスペースに、ワークスペース名プレフィックス付きで現れます: acme_prod.users、acme_stage.users。

ワークスペース間でクエリ

一般的な 3 パターン:

環境間で UNION

> 今週のサインアップ数を本番、ステージング、サンドボックスで比較。

Agent は:

  1. 各フェデレートワークスペースで SELECT count(*) FROM users WHERE created_at > now() - interval '7 days' を実行。
  2. 3 行のテーブルを返します。

ワークスペース間で JOIN

2 つのワークスペースが補完的データを持つとき（共有 clients テーブルがルートに、クライアントごとデータがサブワークスペースに住むコンサルティングでよくあるパターン）:

> ルートからの clients.name と、各クライアントのワークスペースからの先月の売上を JOIN。

クロスワークスペース JOIN は物理 PG Foreign Data Wrapper ではなく論理プロトコルを使います — 異なる Tablize リージョンで動くワークスペースでも動作します。

帰属付き集計

> 先月の全クライアントワークスペースの合計売上、クライアント別に分解。

Agent はファンアウトし、ローカルで集計、統一テーブルを返します。ソートとフィルタリングはルートで発生。

権限

フェデレートされたワークスペースはデフォルトで読み取り専用。ルートはクエリだけができ、insert、update、drop はできません。

ターゲットごとに書き込みアクセスを付与できます — ブランド間で設定を管理する運用ワークスペースに有用 — が、ターゲットの Owner が明示承認する必要があり、すべての書き込みは両方のワークスペースで監査ログに記録されます。

パフォーマンス

フェデレートクエリは並列実行されるため、壁時計時間は最も遅い子クエリです。数ワークスペースをまたぐ小さな JOIN は高速（サブ秒）。大きな JOIN（3 ワークスペースの数百万行）は秒単位。

本当に重いクロスワークスペース分析には、ウェアハウスパターンを検討してください: Snowflake または BigQuery ワークスペースをデータ送信先として設定、各ソースワークスペースがそこに送り、ウェアハウスを直接クエリ。フェデレーションはライブ JOIN ユースケース向けで、重いバッチ向けではありません。

制限

プランフェデレートワークスペース（インバウンド）フェデレーションルート（アウトバウンド）
Plus——
Pro——
Max最大 50最大 10 ルート
Enterprise無制限無制限

これらの制限に達するのは、マルチリージョン Enterprise セットアップ以外では稀です。

セキュリティ

  • ワークスペース間で相互 TLS。すべてのフェデレートクエリはワークスペーススコープのトークンを運びます。
  • すべてのクエリに対し両方のワークスペースで監査ログエントリ。
  • テーブルごと / スキーマごとの共有スコープ — ターゲットが何を見せるか決定。ルートは宣言されたスコープ外のテーブルをクエリできません。
  • 取り消しは即時。ターゲットの Owner はいつでもアクセスを取り消せます。実行中のクエリは古いデータではなくエラーを返します。

フェデレーションの取り消し

ターゲットワークスペースで: Settings → Federation → ルートを見つけ → Revoke。

ルートワークスペースのフェデレートテーブルは即座に読めなくなります。取り消されたテーブルに依存していたルート内の任意の Report / Dashboard / Watch は、明確な「接続取り消し」エラーを表示 — 静かに壊れません。

よくある落とし穴

  • フェデレーション後の「カラムが見つからない」。 ターゲットワークスペースがスキーマを変更。フェデレーションはスキーマ変更を自動伝播しません — Agent にフェデレートワークスペースの再イントロスペクトを頼んでください。
  • クエリがタイムアウト。 子の 1 つが遅い。フェデレーションダッシュボードがワークスペースごとのレイテンシを表示。通常はターゲットの 1 つでインデックス欠落。
  • データが古い。 フェデレーションはデフォルトでライブ読み取りですが、ターゲットでの重い読み取りは、ターゲットが読み取りレプリカを使う場合レプリケーション遅延を引き起こす可能性。修正: プライマリに直接クエリするか、遅延を受け入れる。
  • フェデレーション内のフェデレーション。 現在未対応。A を B にフェデレートして B を C にフェデレートし、C から A をクエリすることはできません。ルートは直接でなければなりません。

次のステップ