setting-up-a-data-warehouse-source

Name: setting-up-a-data-warehouse-source
Author: posthog

github.com/posthogデータ・データベース76377 回インストール今日更新

リポジトリ

setting-up-a-data-warehouse-source について

PostHog のデータウェアハウスに外部データソースを接続するためのスキルです。認証情報の安全な収集と一括セットアップに加え、テーブルや同期方式を手動で選ぶ手順も案内します。

主な機能

01ブラウザー経由で認証情報を安全に受け渡し
021 回の呼び出しでソースを作成
03テーブル検出と同期方法の初期設定
04テーブルと同期方式の手動選択
05Webhook と CDC の設定ガイド

活用シーン

01Stripe や Postgres の新規ソース接続
02同期対象テーブルの選択
03テーブルごとの同期方式の変更
04Webhook 登録や Postgres CDC の設定

MCP 対応

PostHog MCP ツールを使ったデータウェアハウスソースの検出、検証、作成と、スキーマ、Webhook、CDC の設定を案内します。

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/posthog/skills --skill setting-up-a-data-warehouse-source

インストール後、Claude Code で/setting-up-a-data-warehouse-sourceを入力して読み込まれたか確認します。

同梱ファイルreferences/sync-types.md

詳細

データウェアハウスのソースを設定する

ユーザーが外部データソースを初めて PostHog のデータウェアハウスに接続する場合に、このスキルを使用します。

基本はワンステップのフローにします。 data-warehouse-source-setup は認証情報を検証し、すべてのテーブルを検出して、適切な同期のデフォルト設定（可能な場合は増分同期）を適用し、1 回の呼び出しでソースを作成します。schemas 配列を組み立てる必要はありません。認証情報の入力には、チャットで秘密情報を収集する代わりに data-warehouse-source-connect-link で安全なブラウザーリンクをユーザーに渡します。ユーザーが同期するテーブルを個別に選ぶ場合、またはテーブルごとにデフォルト以外の同期タイプを設定する場合に限り、手動の wizard → db-schema → create フローを使用します。

このスキルを使用する場合

ユーザーが新しいソースを接続したい場合：「Stripe を接続して」「Postgres の注文テーブルをインポートして」「Hubspot の連絡先を同期して」
ユーザーが PostHog でサポートされているソースタイプを確認したい場合
ユーザーが認証情報を持っているものの、schemas ペイロードの構成方法がわからない場合
ユーザーがテーブルごとにどの同期方法を選ぶべきか知りたい場合

利用可能なツール

ツール	用途
`data-warehouse-source-connect-link`	認証情報にはこちらを推奨 — ユーザーがチャットに秘密情報を貼り付けずに認証できる、安全なブラウザー／OAuth リンクを取得します
`data-warehouse-source-setup`	作成にはこちらを推奨 — 1 回の呼び出しで認証情報を検証し、テーブルを検出して同期のデフォルト設定を適用し、ソースを作成します
`external-data-sources-wizard`	ソースタイプとそれぞれに必要なフィールドを確認します（高度なフロー）
`external-data-sources-db-schema`	認証情報を検証し、テーブルごとに利用可能な同期方法とともにテーブルを一覧表示します（高度なフロー）
`external-data-sources-create`	高度な作成 — db-schema の応答を基に作成した `schemas` 配列が必要です
`external-data-sources-check-cdc-prerequisites-create`	Postgres CDC の事前チェック（任意。Postgres CDC の場合のみ）
`external-data-sources-webhook-info-retrieve`	ソースが Webhook に対応しているか、Webhook が登録済みかを確認します
`external-data-sources-create-webhook-create`	ソースの作成後に、外部サービスに Webhook を登録します
`external-data-sources-update-webhook-inputs-create`	自動登録に失敗した場合に、署名シークレットを手動で指定します
`external-data-sources-list`	作成後、ソースが一覧に表示されることを確認し、初期ステータスを確認します
`external-data-schemas-list`	ソースの作成後、テーブルごとの同期ステータスを確認します

事前確認：失敗の主な原因となる認証情報の注意点

認証情報を収集する前に、次の点を確認してください。これらは、セットアップが初回で失敗する主な原因です。事前に確認することで、再試行時に認証情報の入力を何度も求めずに済みます。

ホストは PostHog のネットワークから到達可能でなければなりません。 localhost、127.0.0.1、プライベート/RFC-1918 ホスト（10.x、192.168.x、172.16–31.x）は拒否されます。PostHog はユーザーのマシンではなく、独自のインフラストラクチャから接続します。サーバーレス／マネージド Postgres（Neon、Supabase、厳格なルールを設定した RDS）でも、PostHog の送信 IP を先に許可リストに追加する必要があることがよくあります。データベースにパブリックネットワークから到達できない場合は、検証できない認証情報を収集するのではなく、ブラウザーのディープリンク（data-warehouse-source-connect-link）または SSH トンネルを利用してください。
Supabase は Postgres です。二重に収集しないでください。 直接ホストではなく、Session pooler 接続を使用してください（直接ホストは IPv6 のみです）。プーラーのホストは aws-0-<region>.pooler.supabase.com のような形式です。ユーザー名は postgres.<project-ref>、ポートは 6543（5432 ではありません）にする必要があります。パスワードは anon/service_role JWT キーや Supabase アカウントのパスワードとは別の、データベースのパスワード（Settings → Database）です。プロジェクトの環境変数に SUPABASE_URL がある場合は、db.<ref>.supabase.co からプロジェクトの参照値を取得し、ユーザーに推測させずにこれらの値を事前入力してください。
多くの SaaS ソースでは、特定の種類のキーまたはプランが必要です。 作成呼び出しが失敗する前に、適切なものを入手してください。
- Stripe — 標準のシークレットキー（sk_live_…）ではなく、restricted キー（rk_live_…）。
- RevenueCat — 読み取りスコープを有効にした v2 シークレットキー（sk_…）。
- Sentry — DSN や個人用認証トークンではなく、内部統合トークン。
- Convex — Professional プランが必要です。
- Twilio — アカウントの認証トークンではなく、API Key SID + Secret。
- Mailchimp — データセンターのサフィックスを含むキー（key-usX）。
- 送信専用サービス（Resend、Mailgun）では、プロジェクトの環境変数にあるキーが制限付きであることがよくあります。ウェアハウスへのインポートには、フルアクセス／読み取りアクセス可能なキーが必要です。
未解決のシークレット参照を渡さないでください。 認証情報フィールドがまだ {"secretRef": ...} オブジェクトの場合、PostHog はその値を解決できません。作成／db-schema／setup 呼び出しは、明確なエラーを返して拒否します。先に実際の値に解決するか、data-warehouse-source-connect-link を使って認証情報を収集し、結果の credential_id を渡してください。

推奨：ワンステップでのセットアップ

ほとんどのセットアップでは、この方法を使用してください。最もよくある失敗（db-schema の省略、不正な schemas、必須フィールドの不足）を避けられます。

ソースの種類とそのフィールドを確認する（任意）：external-data-sources-wizard を使うと、すべてのソースの種類と、それぞれに必要な認証情報フィールドを一覧表示できます。ユーザーに何を尋ねればよいかを把握するために使用してください。ソースの種類が明らかな場合は省略できます。
認証情報を安全に収集する：data-warehouse-source-connect-link({source_type}) を呼び出します。ソースの完全な接続フォームを表示する最小限の接続ページへの connect_url が返されます。ユーザーは、そのソースで利用できる方法に応じて、OAuth で認可するか、そこで認証情報を入力します（どちらを使うかはレスポンスの auth_method で確認できます）。ページは有効な接続先に対して入力内容を検証し、暗号化して一時ストアに保存します。ソースは作成されません。ユーザーが完了を確認したら、data-warehouse-stored-credentials-list で保存済み認証情報の ID を取得します（source_type で絞り込み、新しい順に表示します。ページにも ID が表示されます）。その後、{"credential_id": <id>} をセットアップに渡します。保存済み認証情報は一度だけ使用でき、セットアップで使用されるとすぐに削除されます。また、24 時間で有効期限が切れます。

データベースのパスワード、API キー、OAuth トークンをそのままチャットに貼り付けるよう、ユーザーに求めてはいけません。
1 回の呼び出しで作成する：data-warehouse-source-setup({source_type, payload, prefix}) を呼び出します。サーバーは認証情報を検証し、すべてのテーブルを検出して、デフォルトの同期設定で有効にします（追跡カラムがある場合は増分同期、なければ追記同期、それもなければ全件更新。CDC は使用しません）。さらに created_via=mcp を設定して、ソースを作成します。payload には認証情報への参照（{"credential_id": ...} または OAuth インテグレーション ID のキー）を指定します。ヘッドレス自動化の場合は、認証情報を直接指定することもできます。schemas 配列は不要です。成功すると新しいソースの id が返されます。external-data-schemas-list を呼び出して、有効になった内容と、各テーブルの同期方法をユーザーに提示してください。

この方法に固有の注意事項：

検出されたテーブルはすべて有効になります。 これは意図した動作です（増分同期のデフォルト設定により、継続的なコストを抑えられます）。ただし、非常に大きなテーブルについては行数を知らせ、ユーザーが一部のテーブルだけを同期したい場合は、上級者向けのフローを案内してください。
Webhook は対応するソースで自動登録されます（現在は Stripe）。セットアップレスポンスの webhook キーを確認してください。成功すると、Webhook 対応テーブルはリアルタイムで同期され、Webhook のみのテーブル（例：Stripe Discount）も有効になります。失敗した場合（例：API キーで Webhook を作成できない場合）、テーブルはポーリングのデフォルト設定を維持し、Webhook のみのテーブルは無効のままになります。webhook.error をユーザーに伝え、手動で登録するための Step 6 を案内してください。webhook.pending_inputs が空でない場合は、その値を収集し、external-data-sources-update-webhook-inputs-create で送信してください。CDC が自動的に選択されることはありません。Postgres でほぼリアルタイムの同期を行う場合は、上級者向けフローと CDC の手順を使用してください。
payload に認証情報を直接指定する方法も、ヘッドレス環境や自動化では引き続き使用できますが、上記の接続リンクを使った引き継ぎを優先してください。

上級者向け：テーブルを手動で選択する（3 ステップのフロー）

ユーザーが同期するテーブルを正確に選びたい場合や、デフォルト以外の同期タイプを設定したい場合に使用してください。external-data-sources-create に直接進む近道は使わないでください。有効な schemas ペイロードを作成するには、db-schema のレスポンスが必要です。

         ┌────────────────────┐
         │ 1. wizard          │  What source types exist? What fields does each need?
         └────────┬───────────┘
                  ▼
         ┌────────────────────┐
         │ 2. db-schema       │  Validate creds. List tables + available sync methods per table.
         └────────┬───────────┘
                  ▼
         ┌────────────────────┐
         │ 3. create          │  Send source_type + credentials + schemas[] to actually create.
         └────────────────────┘

ワークフロー

ステップ 1 — ソースの種類を確認する

必要な種類を source_type に指定して、external-data-sources-wizard を呼び出します（複数指定する場合はカンマ区切りにします。例： Postgres,Stripe）。フィルターを指定しない場合、サポート対象のすべてのソースが返され、サイズは数百 KB に及ぶため、コンテキストの予算を超える可能性があります。利用可能な種類をすべて列挙する必要が本当にある場合に限り、source_type を省略してください。その場合は fields: ['*.name', '*.caption'] を渡して、各ソースの設定フィールド定義ではなく名前だけが返されるようにします。レスポンスはソースの種類をキーとする辞書です。各エントリには次の情報が含まれます。

name — 後続の呼び出しで渡す正式な source_type 文字列（例："Postgres"、"Stripe"、"Hubspot"）。
caption — 人が読める説明。
fields — 必要な設定フィールド（host、port、database、api_key、client_id/secret など）。各フィールドには name、type（input、password、switch、select、file-upload）、required が含まれます。
featured、unreleasedSource — 利用準備状況の目安として使います。ユーザーがプレビューを明示的に希望しない限り、unreleasedSource: true とマークされたソースは対象外にします。

ユーザーの依頼に合うソースを選びます。「Postgres」と言われた場合は Postgres を確認します。「database」のように曖昧な場合は、関連性の高い候補（Postgres、MySQL、MongoDB、BigQuery、Snowflake、Redshift）を提示して選んでもらいます。

OAuth ベースのソース（Hubspot、Salesforce、Google Ads）では、ウィザードのエントリから OAuth フローが必要だと分かります。通常、認証情報を貼り付けてもらうのではなく、PostHog UI で認証してもらう必要があります。この点を説明し、チャットでトークンを集めようとせず、ソースのセットアップページに案内してください。OAuth は「認証」に関するものであり、データの流れ方とは関係ありません。OAuth ソースも、ウェブフックではなくポーリングによる一括同期を使います。

ユーザーから必要な認証情報を集めます。ウィザードのエントリで必須とされている以上のフィールドを尋ねないでください。ソースで不要な port を尋ねると、ユーザーを混乱させます。

ステップ 2 — 認証情報を検証し、テーブルを確認する

source_type とすべての認証情報フィールドを指定して、external-data-sources-db-schema を呼び出します。この呼び出しでは、次の 2 つを同時に行います。

稼働中のソースに対して認証情報を検証します。問題があれば、message を含む 400 が返されます（ホストの誤り、パスワードの誤り、権限不足など）。エラーはそのままユーザーに示してください。多くの場合、解決に役立つ情報が含まれています（「user 'x' のパスワード認証に失敗しました」など）。
認証情報が有効な場合は、テーブルエントリの配列が返されます。各エントリには次の情報が含まれます。

{
  "table": "orders",
  "should_sync": false,
  "rows": 1_250_000,
  "incremental_available": true,   # can do sync_type=incremental
  "append_available": true,        # can do sync_type=append
  "cdc_available": true,           # can do sync_type=cdc  (null = not enabled for team)
  "supports_webhooks": false,      # can do sync_type=webhook for real-time push
  "incremental_fields": [          # candidates: usually updated_at, created_at, id
    {"field": "updated_at", "type": "datetime", "label": "updated_at", ...},
    {"field": "created_at", "type": "datetime", ...},
    {"field": "id", "type": "integer", ...}
  ],
  "detected_primary_keys": ["id"],
  "available_columns": [{"field": "id", "type": "integer", "nullable": false}, ...],
  "description": "..."
}

この内容をユーザーに提示します。生の JSON をそのまま出力するのではなく、見つかったテーブル、行数、テーブルごとのデフォルトの同期方法の推奨を要約してください（同期タイプの判断ガイドを参照）。

ステップ 3 — テーブルごとの同期設定を確認する

ユーザーが同期したい各テーブルについて、sync_type を選びます。詳細なルールについては sync-type decision guideを参照してください。要点は次のとおりです。

小規模なテーブル／ディメンションテーブル（5万行未満で、自然な順序を示す列がない）： full_refresh — シンプルで、常に正確です。
updated_at／modified_at がある大規模なテーブル： incremental — 同期ごとのコストを大幅に抑えられます。
追記専用で不変のテーブル（ログ、イベント）： 利用できる場合は append — 履歴を保持できます。
CDC が有効で、ほぼリアルタイムの同期が必要な Postgres： cdc — 主キーと Postgres の前提条件が必要です。
Webhook に対応しているソース（現在は Stripe）： ほぼリアルタイムの取り込みを行うには、supports_webhooks: true のテーブルで sync_type: "webhook" を設定し、その後の作成ステップとして Webhook を登録します（下記のステップ 6 を参照）。同じソース内で Webhook に対応していないテーブルには、引き続き一括同期の sync_type が必要です。

incremental／append／cdc を使用する各スキーマには、次の項目も必要です。

incremental_field — 高水位マークの順序付けに使用する列を指定します。db-schema が返す incremental_fields のリストから選択してください。created_at より updated_at を優先します（updated_at なら後から到着した更新を捕捉できますが、created_at では捕捉できません）。整数のみのテーブルでは、単調増加する主キーを使用します。
incremental_field_type — 選択したフィールドの型（datetime、timestamp、date、integer、numeric、objectid）と一致させる必要があります。
primary_key_columns — CDC に必須です。db-schema の detected_primary_keys を使用してください。

ステップ 4 — 適切なプレフィックスを選ぶ

ソースの prefix は HogQL のテーブル名の先頭に付加されます。テーブル名は {prefix}_{table_name} になります。

その種類のソースが 1 つだけの場合は、ソースの種類を小文字にしたものをデフォルトで使用します：stripe、postgres。
ユーザーがすでに Postgres ソースを持っている場合は、区別できる名前を選びます：postgres_prod、postgres_analytics。
小文字とアンダースコアを使用します。プレフィックスは、ユーザーが作成するすべての HogQL クエリの一部になります。

ソースを作成する前に、プレフィックスをユーザーに確認してください。後から変更することもできますが、すべてのテーブル名が変更されます。

ステップ 5 — ソースを作成する

external-data-sources-create を次の内容で呼び出します。

{
  "source_type": "Postgres",
  "prefix": "postgres_prod",
  "payload": {
    "host": "...",
    "port": "5432",
    "dbname": "...",
    "user": "...",
    "password": "...",
    "schema": "public",
    "schemas": [
      {
        "name": "orders",
        "should_sync": true,
        "sync_type": "incremental",
        "incremental_field": "updated_at",
        "incremental_field_type": "datetime",
        "primary_key_columns": ["id"]
      },
      {
        "name": "users",
        "should_sync": true,
        "sync_type": "full_refresh"
      },
      {
        "name": "audit_log",
        "should_sync": false
      }
    ]
  }
}

schemas 配列のルール：

db-schema が返すすべてのテーブルを含める必要があります。ユーザーが必要としていないテーブルも含めてください（should_sync: false を設定します）。ユーザーが言及していないテーブルのデフォルトは should_sync: false です。
sync_type が必要なのは、should_sync: true の場合のみです。
sync_type が incremental または append の場合、incremental_field／incremental_field_type を指定する必要があります。
sync_type が cdc の場合、primary_key_columns を指定する必要があります。

成功すると、新しい id を持つソースが返されます。最初の同期は自動的に開始されます。

ステップ 6 — Webhook を登録する（いずれかのスキーマが `sync_type: "webhook"` の場合のみ）

Webhook タイプのスキーマは、存在するだけではデータの受信を開始しません。外部サービスに POST イベントの送信先を知らせ、PostHog にその検証方法を知らせる必要があります。これはソースの作成後に行う 2 回目の呼び出しであり、external-data-sources-create のペイロードには含まれません。セットアップが完了したとユーザーに伝える前に実行してください。そうしないと、プッシュチャネルが未登録のまま「同期が実行中です」と伝えることになります。

ソース上の少なくとも 1 つのスキーマで sync_type: "webhook" と should_sync: true の両方が設定されている場合にのみ必要です。現在、このフローを実装しているのは Stripe だけです。それ以外では、このステップを省略してください。

create-webhook を呼び出す前に、external-data-sources-webhook-info-retrieve({id}) を確認してください。すでに exists: true が返される場合は、create-webhook を再度呼び出さないでください。呼び出しが成功するたびに新しい外部エンドポイントが登録され、重複配信が発生します。

external-data-sources-create-webhook-create({id}) を呼び出します。PostHog は以下を行います。
- Webhook の POST を受信する HogFunction を作成します。
- 外部イベントタイプから PostHog スキーマ ID への schema_mapping を構築します。
- ソースの API（Stripe など）を呼び出し、Webhook URL を登録して関連イベントを購読します。
- Stripe では、signing_secret を自動的に取得して安全に保存します。
{success, webhook_url, error} が返されます。成功した場合は、記録用に webhook_url をユーザーに伝えてください。ただし、ユーザーがどこかに貼り付ける必要はありません。登録はすでに完了しています。
「API key doesn't have permission to create webhooks」のような権限エラーで success: false が返された場合：
- HogFunction は作成されていますが、無効になっています。
- 返された webhook_url を使用して、ソースのダッシュボードで Webhook を手動作成するようユーザーに依頼します。
- ソースの Webhook 設定から signing secret をコピーするよう伝えます。
- external-data-sources-update-webhook-inputs-create({id}, {inputs: {signing_secret: "whsec_..."}}) を呼び出して保存します。HogFunction はこの値を取得し、受信ペイロードを検証します。
external-data-sources-webhook-info-retrieve({id}) で確認します。正常な Webhook では exists: true、external_status.status: "enabled" が返され、error はありません。

Webhook は一括同期を補完するものです。Webhook が有効なスキーマの初回読み込みも、引き続きポーリングで行われます（完了すると initial_sync_complete が true になります）。その後、Webhook が主な取り込み経路になります。Webhook スキーマには、安全策として定期的な一括更新をスケジュールする sync_frequency も設定されます。これは想定された動作であり、「修正」する必要はありません。

ステップ 7 — 次に何が起こるかを確認して説明する

作成後（Webhook スキーマの場合は、ステップ 6 の完了後）：

external-data-schemas-list を呼び出し、初期状態をユーザーに表示します。
有効な各スキーマは Running になり、初回同期が完了すると Completed に移行すると説明します。初回同期にかかる時間は、行数によって数秒から数時間までさまざまです。数百万行のテーブルでも問題ありませんが、時間はかかります。
HogQL で SELECT * FROM {prefix}_{table_name} LIMIT 10 を使ってクエリする方法を伝えます。
数分後に状況を再確認し、初回同期が成功したか確認することを提案します。

Postgres の CDC セットアップ（任意、ユーザーから依頼された場合）

ユーザーが Postgres からほぼリアルタイムのレプリケーションを希望する場合：

db-schema を呼び出す前に、ユーザーの Postgres 認証情報を使って external-data-sources-check-cdc-prerequisites-create を実行します。{valid, errors[]} が返され、不足している項目（wal_level、replication slot、publication、権限）が一覧表示されます。
valid: false の場合は、エラーを提示し、Postgres 側で修正するようユーザーに依頼します。すぐに失敗する CDC ソースを作成しようとしないでください。
前提条件が満たされたら、db-schema に進み、作成します。必要なテーブルには sync_type: "cdc" を設定し、それぞれに primary_key_columns を含めます（CDC では必須です）。

重要な注意事項

作成前に必ず db-schema で認証情報を検証してください。 作成エンドポイントは無効な認証情報も受け付け、その後非同期で失敗します。ソースはステータスが Error でテーブルがない状態で一覧に表示されます。検証手順を省略しても、失敗がバックグラウンドに回るだけです。
作成前にテーブル一覧を提示してください。 大規模なデータベースには、数百ものテーブルがある場合があります。すべてを自動選択しないでください。請求額には行数と関連性が影響します。ユーザーが明示的に選択できるようにしてください。
スキーマを捏造しないでください。 schemas 配列の各エントリは、db-schema のレスポンスにある実在のテーブルに対応している必要があります。db-schema で見つからない限り、「orders テーブルも追加する」ことはできません。
新しいソースは PostHog ウェアハウスに同期されます。 これがデフォルトで、設定は不要です。送信先を設定していないソースは、ここにのみ書き込まれます。プロジェクトによっては、ソースのテーブルを独自のデータベースにも送信できます（プロジェクトでこの機能が有効な場合、external-data-sources-destinations-retrieve でソースの書き込み先を確認できます）。その設定は別の手順で行うもので、ソース作成の一環として行ってはいけません。すでに同期済みのソースに送信先を追加しても、テーブルを再同期するまでは履歴データが一切保持されません。また、再同期ではソースのすべての書き込み先が課金対象になります。
プレフィックスは重要です。 これは、ユーザーがこれらのテーブルに対して作成するすべての HogQL クエリで使われます。短く、内容が分かりやすく、未使用のものを選んでください。
認証情報には、セキュアな接続リンクを優先してください。 data-warehouse-source-connect-link を使うと、ユーザーはブラウザーで認証できます。接続ページにはソースの接続フォーム全体（OAuth と認証情報の両方のオプション）が表示され、ソースを作成せずに接続情報が保存されます。OAuth トークンやデータベースのパスワードをチャットで収集しないでください。設定には credential_id の参照を渡してください。ソースの作成は常に設定を通じて行い、UI からは行いません。（すでに接続済みの OAuth 統合は、ID キーを使って直接渡すこともできます。例：{"hubspot_integration_id": 123}。）
Webhook の設定は作成後の別手順です。 スキーマに sync_type: "webhook" を設定しても、Webhook は登録されません。登録には create-webhook の呼び出しが必要です。Webhook タイプのスキーマでは、必ず create → create-webhook → webhook-info の順に実行し、登録せずに放置しないでください。登録しないとイベントを受信できません。
Webhook のサポートはソースごとに異なり、対応ソースは限られています。 現在 WebhookSource を実装しているのは Stripe のみです。Hubspot、Salesforce、Postgres で Webhook を使えると約束しないでください。これらはポーリング同期を使用します。
行数が請求額を左右します。 ウェアハウス同期は同期した行数に応じて課金されます。頻繁に更新される 5 億行の events テーブルを毎時同期する場合と、1 万行のディメンションテーブルを毎日同期する場合では、大きな違いがあります。大きなテーブルには注意を促し、デフォルトとして、より長い同期頻度（sync_frequency: "24hour"）を提案してください。

Markdown 対応

ログインしてコメント

基本情報

作者: posthog
リポジトリ: posthog/skills
カテゴリ: データ・データベース
インストール数: 377
GitHub スター: 76

問題を報告