PostHog 数据仓库源同步类型Sync Type完整决策指南从 full_refresh 到 CDC 与 Webhook【免费下载链接】posthog:hedgehog: PostHog is the leading platform for building self-driving products. Our developer tools – AI observability, analytics, session replay, flags, experiments, error tracking, logs, and more – capture all the context agents need to diagnose problems, uncover opportunities, and ship fixes. Steer it all from Slack, web, desktop, or the MCP.项目地址: https://gitcode.com/GitHub_Trending/po/posthog本篇指南围绕 PostHog 数据仓库源Data Warehouse Source中每个表的sync_type选择展开系统讲解五种同步类型的适用场景、incremental_field与incremental_field_type的配对规则、primary_key_columns的必要性、CDC 的cdc_table_mode形态选择、webhook 的两步注册流程以及sync_frequency频率的取值与推荐。读完本文你将能够为任意表选择正确的同步方式并通过 MCP 工具链db-schema→create→create-webhook完整落地配置同时理解 PostHog 底层模型与调度器是如何执行这些设置的。为什么每个表都要一个sync_type在 PostHog 的数据仓库源中ExternalDataSchema的sync_type决定了每次同步时数据如何流动、同步成本多高、数据多新鲜以及导入后在仓库中以什么形态存在。它被持久化在每张表的 schema 记录上字段sync_type见 external_data_schema.py并在运行时驱动提取extract、加载load流水线的具体行为。从源码看PostHog 在 facade/types.py 中把同步类型定义为枚举ExternalDataSchemaSyncType除文档重点介绍的五种外还保留了一个内部使用的xmin类型Postgres 系统游标不面向常规配置class ExternalDataSchemaSyncType(models.TextChoices): FULL_REFRESH full_refresh, full_refresh INCREMENTAL incremental, incremental APPEND append, append WEBHOOK webhook, webhook CDC cdc, cdc XMIN xmin, xmin模型上还提供了is_incremental、is_append、is_webhook、is_cdc等便捷属性external_data_schema.pyshould_use_incremental_field则表明incremental、append、webhook三种类型共享按增量字段推进水位线的语义。五种同步类型一览同步类型行为必要条件适用场景full_refresh每次同步丢弃全部数据、整表重新导入无小表、维度表拿不准时选它incremental只导入incremental_field last_value的行incremental_fieldincremental_field_type拥有updated_at/modified_at的大表append类似 incremental但保留行的历史版本incremental_fieldincremental_field_type不可变或仅追加的表事件、日志cdc通过 Postgres 逻辑复制流式同步变更Postgres、主键、wal_levellogical近实时、大体积 Postgres 表webhook源侧 Webhook 实时推送源必须实现WebhookSource支持它的源的近实时推送如 Stripe需要特别说明的是并非所有源都支持所有类型。db-schema响应会在每个表上以incremental_available、append_available、cdc_available、supports_webhooks四个布尔标记暴露可用能力字段说明见 SKILL.md 中 Step 2 的响应示例。配置前应先以此为准而不是凭源类型猜测。此外cdc_available为null时代表该团队尚未启用 CDC 能力。在一次性建源流程data-warehouse-source-setup中PostHog 的默认策略是存在跟踪列时选incremental否则选append再否则选full_refresh从不自动选 CDC见 SKILL.md 的 Recommended 章节需要近实时 Postgres 时必须走高级流程手动配置 CDC。如何选择按表特征对号入座小表、没有明显的排序列→full_refresh。约 5 万行以内的表每日全量刷新成本足够低。如果找不到干净的updated_at不要伪造增量同步——硬凑只会让水位线失去意义。大表且有updated_at/modified_at→ 用该字段做incremental。这是最常见的情形每次同步只拉取自高水位线high-water mark以来变更的行成本显著降低。大表但只有created_at→ 可以用created_at做incremental但必须向用户说明created_at只能捕获新行已有行的更新会被漏掉。对不可变记录没问题对可变记录则是错误选择。大表没有好时间戳但有单调递增的整型 id→ 用 id 做incrementalincremental_field_type: integer原理相同——新行 id 更大。不可变事件 / 日志表→ 可用时选append否则incremental。append保留每个版本适合源会更新记录而你希望追踪历史而非只保留最新状态的情况。Postgres 且需要亚分钟级新鲜度→cdc。CDC 通过 WAL 流而非轮询获取变更。需要每张表都有主键且完成 Postgres 逻辑复制的前置配置。务必先运行external-data-sources-check-cdc-prerequisites-create前置条件不满足会导致首次运行立即失败。该工具返回{valid, errors[]}列出缺失项wal_level、replication slot、publication、权限具体流程见 SKILL.md 的 CDC 章节。Stripe或任何supports_webhooks: true的源→ 可考虑webhook做实时推送。注意两点webhook 类型的 schema仍然会先做一次初始全量加载再切换到推送模式并且会保留一个sync_frequency用于周期性对账另外建源后还必须调用external-data-sources-create-webhook-create完成注册——设置sync_type是必要但不充分的条件。同一源上不支持 webhook 的表仍需配置常规的批量sync_type。挑选incremental_field优先级顺序incremental_field必须出现在db-schema返回的incremental_fields列表中。并非所有列都合格——源只会暴露它能低成本过滤的 timestamp / integer / ObjectID 列。响应中的每个候选字段还带有is_indexed标记facade/types.py 中的IncrementalField结构用于提示选择会导致每次同步全表扫描的字段。优先级顺序从高到低updated_at/modified_at/last_modified/hs_lastmodifieddate—— 同时捕获插入与更新首选。created_at/inserted_at—— 只捕获插入不捕获更新。仅当确认表不可变时使用。单调递增的整型主键id、sequence_number—— 与created_at相同的取舍。MongoDB_idObjectId—— 可按创建时间排序天然适合 Mongo。incremental_field_type取值与配对规则incremental_field_type必须与所选字段的实际类型匹配datetime—TIMESTAMP、DATETIME、TIMESTAMP WITH TIME ZONEdate—DATEtimestamp— unix 纪元整型时间戳integer—INT、BIGINT、SERIALnumeric—NUMERIC、DECIMAL值需单调递增objectid— MongoDB ObjectId这些取值对应源码中 facade/types.py 的IncrementalFieldType枚举此外源码还定义了 Postgres 专用的xidxmin 系统列内部使用。如果所选字段与声明的类型不匹配首次同步会以类型强制转换type coercion错误失败。水位线的实际存储也依赖类型模型会把incremental_field_last_value/incremental_field_earliest_value序列化进sync_type_config序列化逻辑按类型区分处理整数/数值类型直接存值、datetime/timestamp 存 ISO 字符串见 external_data_schema.py。这也解释了为什么类型必须配对正确——错误类型会导致水位线比较行为异常或直接报错。primary_key_columnsCDC 的硬性要求primary_key_columns对cdc是必需的对可能发生更新的incremental表则强烈建议配置因为它用于 upsert 去重。配置建议有detected_primary_keys时直接使用 db-schema 返回的检测结果。源未检测到、但你确认表存在自然键时显式传入。表确实没有唯一键时避免使用cdc——同步会以 Primary key required for incremental syncs 或 primary keys for this table are not unique 失败。这两条错误信息在源码中有精确对应。模型文件 external_data_schema.py 定义了MISSING_PRIMARY_KEYS_RAW_ERROR Primary key required for incremental syncs和DUPLICATE_PRIMARY_KEYS_RAW_ERROR The primary keys for this table are not unique并通过incremental_sync_blocked_reason()把这两类错误归类为missing_primary_key/duplicate_primary_key对应IncrementalSyncBlockedReason枚举见 facade/types.py。这是设计上的关键点这类失败重试无法修复必须修改配置换主键或换同步方式PostHog 会据此判断是否需要自动停用该 schema。cdc_table_mode仅 CDC同步表的长相对 CDC schemacdc_table_mode决定同步到仓库的表呈现为什么形态存储在sync_type_config中模型默认值consolidated见 external_data_schema.pyconsolidated默认—— 表反映每一行的当前状态旧版本被覆盖。最适合操作型查询。cdc_only—— 表是每次变更事件insert / update / delete的仅追加日志没有当前状态视图。both—— 同时保留一张合并后的当前状态表与一张独立的 CDC 日志表。最灵活但存储翻倍。需要提醒的是文档所述模式均以源码为准配置 CDC 前建议先用external-data-sources-check-cdc-prerequisites-create确认前置条件Postgres 逻辑复制、wal_levellogical、复制槽与发布对象、账号权限避免首次运行即失败。Webhook 是两步设置建源之外还要注册与其他同步类型不同webhook在建源之后还需要第二次 API 调用在支持 webhook 的表上以sync_type: webhook创建源。调用external-data-sources-create-webhook-create({id})向外部服务注册 webhook并创建处理入站事件的 HogFunction。跳过第 2 步webhook 类型的 schema 就会一直空转、没有任何数据流入。create-webhook实际完成的工作包括创建接收 webhook POST 的 HogFunction、构建外部事件类型到 PostHog schema id 的映射、调用源侧 API如 Stripe注册 webhook URL 并订阅相关事件且在 Stripe 上会自动捕获signing_secret并安全存储流程见 SKILL.md 的 Step 6。如果外部服务不允许 PostHog 自动注册通常是所存 API key 缺少 webhook 权限则回退到手动设置在源的控制台注册 webhook然后通过external-data-sources-update-webhook-inputs-create提交签名密钥signing secret。这种情况下 HogFunction 仍会被创建只是处于禁用状态提交密钥后即可启用。两个重要细节调用前先查重调用external-data-sources-webhook-info-retrieve({id})若已返回exists: true就不要再调create-webhook——每次成功调用都会注册一个新的外部端点导致重复投递。WebhookSource是源码事实只有实现了WebhookSource接口的源类型才支持sync_type: webhook目前只有 Stripe。db-schema 响应中每个表的supports_webhooks标记才是可用性的唯一事实来源不要对 Hubspot、Salesforce、Postgres 承诺 webhook——它们走轮询同步详见 SKILL.md 的 Important notes。webhook 是批量同步的补充而非替代webhook 类型 schema 的首次加载仍通过轮询完成initial_sync_complete翻转为true后切换为推送之后 webhook 成为主要摄入路径同时保留sync_frequency周期性地做一次批量对账兜底——这是预期行为不是需要修复的问题。Sync frequency与sync_type正交的调度频率sync_frequency是 per-schema 的独立选项与sync_type正交。合法值由小到大为5min、15min、30min、1hour、6hour、12hour、24hour、7day、30day、never。5min是所有同步类型的下限——API 会拒绝更快的频率。不同场景的推荐值full_refresh非平凡大小表默认24hour——每次运行都重新导入全表低于小时级的频率通常只是浪费。incremental/append合理大小表上1hour或6hour是合理默认。5min下限存在但很少需要——用户若追求实时优先推荐cdc或webhook。cdc频率基本不适用——CDC 是持续流式同步。冷归档表7day或30day保持调度存活、避免浪费运行。never值会冻结 schema——不再自动同步但仍可通过external-data-schemas-reload手动触发。在源码层面频率以sync_frequency_intervalDurationField默认 6 小时和sync_time_of_dayUTC 时分持久化见 external_data_schema.pyMCP 工具external-data-sources-update-schema也支持更新频率与 UTC 时段见 tools.yaml。一份可复用的配置示例结合上面的规则一个 Postgres 源的schemas数组可以这样组织完整示例见 SKILL.md 的 Step 5{ 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], sync_frequency: 1hour }, { name: users, should_sync: true, sync_type: full_refresh, sync_frequency: 24hour }, { name: audit_log, should_sync: false } ] } }schemas数组的约束db-schema 返回的每张表都应出现在数组中不想同步的置should_sync: falsesync_type仅在should_sync: true时必填incremental_field/incremental_field_type在sync_type为incremental或append时必须提供primary_key_columns在sync_type为cdc时必须提供。若其中任何一张表使用了sync_type: webhook建源后务必补上create-webhook这第二步。小结同步类型的选择本质上是成本、新鲜度、数据形态三角的权衡full_refresh最简单但每次全量重导incremental/append用水位线控制成本、适合大多数轮询场景cdc用逻辑复制换取亚分钟级新鲜度代价是主键与 Postgres 前置条件webhook提供真正的实时推送但只在实现WebhookSource的源当前为 Stripe上可用且需要单独的注册步骤。配置前以db-schema响应中的能力标记和候选字段为准配置后以external-data-schemas-list观察每张表的同步状态即可稳定落地一套贴合数据形态的同步方案。【免费下载链接】posthog:hedgehog: PostHog is the leading platform for building self-driving products. Our developer tools – AI observability, analytics, session replay, flags, experiments, error tracking, logs, and more – capture all the context agents need to diagnose problems, uncover opportunities, and ship fixes. Steer it all from Slack, web, desktop, or the MCP.项目地址: https://gitcode.com/GitHub_Trending/po/posthog创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
PostHog 数据仓库源同步类型（Sync Type）完整决策指南：从 full_refresh 到 CDC 与 Webhook
PostHog 数据仓库源同步类型Sync Type完整决策指南从 full_refresh 到 CDC 与 Webhook【免费下载链接】posthog:hedgehog: PostHog is the leading platform for building self-driving products. Our developer tools – AI observability, analytics, session replay, flags, experiments, error tracking, logs, and more – capture all the context agents need to diagnose problems, uncover opportunities, and ship fixes. Steer it all from Slack, web, desktop, or the MCP.项目地址: https://gitcode.com/GitHub_Trending/po/posthog本篇指南围绕 PostHog 数据仓库源Data Warehouse Source中每个表的sync_type选择展开系统讲解五种同步类型的适用场景、incremental_field与incremental_field_type的配对规则、primary_key_columns的必要性、CDC 的cdc_table_mode形态选择、webhook 的两步注册流程以及sync_frequency频率的取值与推荐。读完本文你将能够为任意表选择正确的同步方式并通过 MCP 工具链db-schema→create→create-webhook完整落地配置同时理解 PostHog 底层模型与调度器是如何执行这些设置的。为什么每个表都要一个sync_type在 PostHog 的数据仓库源中ExternalDataSchema的sync_type决定了每次同步时数据如何流动、同步成本多高、数据多新鲜以及导入后在仓库中以什么形态存在。它被持久化在每张表的 schema 记录上字段sync_type见 external_data_schema.py并在运行时驱动提取extract、加载load流水线的具体行为。从源码看PostHog 在 facade/types.py 中把同步类型定义为枚举ExternalDataSchemaSyncType除文档重点介绍的五种外还保留了一个内部使用的xmin类型Postgres 系统游标不面向常规配置class ExternalDataSchemaSyncType(models.TextChoices): FULL_REFRESH full_refresh, full_refresh INCREMENTAL incremental, incremental APPEND append, append WEBHOOK webhook, webhook CDC cdc, cdc XMIN xmin, xmin模型上还提供了is_incremental、is_append、is_webhook、is_cdc等便捷属性external_data_schema.pyshould_use_incremental_field则表明incremental、append、webhook三种类型共享按增量字段推进水位线的语义。五种同步类型一览同步类型行为必要条件适用场景full_refresh每次同步丢弃全部数据、整表重新导入无小表、维度表拿不准时选它incremental只导入incremental_field last_value的行incremental_fieldincremental_field_type拥有updated_at/modified_at的大表append类似 incremental但保留行的历史版本incremental_fieldincremental_field_type不可变或仅追加的表事件、日志cdc通过 Postgres 逻辑复制流式同步变更Postgres、主键、wal_levellogical近实时、大体积 Postgres 表webhook源侧 Webhook 实时推送源必须实现WebhookSource支持它的源的近实时推送如 Stripe需要特别说明的是并非所有源都支持所有类型。db-schema响应会在每个表上以incremental_available、append_available、cdc_available、supports_webhooks四个布尔标记暴露可用能力字段说明见 SKILL.md 中 Step 2 的响应示例。配置前应先以此为准而不是凭源类型猜测。此外cdc_available为null时代表该团队尚未启用 CDC 能力。在一次性建源流程data-warehouse-source-setup中PostHog 的默认策略是存在跟踪列时选incremental否则选append再否则选full_refresh从不自动选 CDC见 SKILL.md 的 Recommended 章节需要近实时 Postgres 时必须走高级流程手动配置 CDC。如何选择按表特征对号入座小表、没有明显的排序列→full_refresh。约 5 万行以内的表每日全量刷新成本足够低。如果找不到干净的updated_at不要伪造增量同步——硬凑只会让水位线失去意义。大表且有updated_at/modified_at→ 用该字段做incremental。这是最常见的情形每次同步只拉取自高水位线high-water mark以来变更的行成本显著降低。大表但只有created_at→ 可以用created_at做incremental但必须向用户说明created_at只能捕获新行已有行的更新会被漏掉。对不可变记录没问题对可变记录则是错误选择。大表没有好时间戳但有单调递增的整型 id→ 用 id 做incrementalincremental_field_type: integer原理相同——新行 id 更大。不可变事件 / 日志表→ 可用时选append否则incremental。append保留每个版本适合源会更新记录而你希望追踪历史而非只保留最新状态的情况。Postgres 且需要亚分钟级新鲜度→cdc。CDC 通过 WAL 流而非轮询获取变更。需要每张表都有主键且完成 Postgres 逻辑复制的前置配置。务必先运行external-data-sources-check-cdc-prerequisites-create前置条件不满足会导致首次运行立即失败。该工具返回{valid, errors[]}列出缺失项wal_level、replication slot、publication、权限具体流程见 SKILL.md 的 CDC 章节。Stripe或任何supports_webhooks: true的源→ 可考虑webhook做实时推送。注意两点webhook 类型的 schema仍然会先做一次初始全量加载再切换到推送模式并且会保留一个sync_frequency用于周期性对账另外建源后还必须调用external-data-sources-create-webhook-create完成注册——设置sync_type是必要但不充分的条件。同一源上不支持 webhook 的表仍需配置常规的批量sync_type。挑选incremental_field优先级顺序incremental_field必须出现在db-schema返回的incremental_fields列表中。并非所有列都合格——源只会暴露它能低成本过滤的 timestamp / integer / ObjectID 列。响应中的每个候选字段还带有is_indexed标记facade/types.py 中的IncrementalField结构用于提示选择会导致每次同步全表扫描的字段。优先级顺序从高到低updated_at/modified_at/last_modified/hs_lastmodifieddate—— 同时捕获插入与更新首选。created_at/inserted_at—— 只捕获插入不捕获更新。仅当确认表不可变时使用。单调递增的整型主键id、sequence_number—— 与created_at相同的取舍。MongoDB_idObjectId—— 可按创建时间排序天然适合 Mongo。incremental_field_type取值与配对规则incremental_field_type必须与所选字段的实际类型匹配datetime—TIMESTAMP、DATETIME、TIMESTAMP WITH TIME ZONEdate—DATEtimestamp— unix 纪元整型时间戳integer—INT、BIGINT、SERIALnumeric—NUMERIC、DECIMAL值需单调递增objectid— MongoDB ObjectId这些取值对应源码中 facade/types.py 的IncrementalFieldType枚举此外源码还定义了 Postgres 专用的xidxmin 系统列内部使用。如果所选字段与声明的类型不匹配首次同步会以类型强制转换type coercion错误失败。水位线的实际存储也依赖类型模型会把incremental_field_last_value/incremental_field_earliest_value序列化进sync_type_config序列化逻辑按类型区分处理整数/数值类型直接存值、datetime/timestamp 存 ISO 字符串见 external_data_schema.py。这也解释了为什么类型必须配对正确——错误类型会导致水位线比较行为异常或直接报错。primary_key_columnsCDC 的硬性要求primary_key_columns对cdc是必需的对可能发生更新的incremental表则强烈建议配置因为它用于 upsert 去重。配置建议有detected_primary_keys时直接使用 db-schema 返回的检测结果。源未检测到、但你确认表存在自然键时显式传入。表确实没有唯一键时避免使用cdc——同步会以 Primary key required for incremental syncs 或 primary keys for this table are not unique 失败。这两条错误信息在源码中有精确对应。模型文件 external_data_schema.py 定义了MISSING_PRIMARY_KEYS_RAW_ERROR Primary key required for incremental syncs和DUPLICATE_PRIMARY_KEYS_RAW_ERROR The primary keys for this table are not unique并通过incremental_sync_blocked_reason()把这两类错误归类为missing_primary_key/duplicate_primary_key对应IncrementalSyncBlockedReason枚举见 facade/types.py。这是设计上的关键点这类失败重试无法修复必须修改配置换主键或换同步方式PostHog 会据此判断是否需要自动停用该 schema。cdc_table_mode仅 CDC同步表的长相对 CDC schemacdc_table_mode决定同步到仓库的表呈现为什么形态存储在sync_type_config中模型默认值consolidated见 external_data_schema.pyconsolidated默认—— 表反映每一行的当前状态旧版本被覆盖。最适合操作型查询。cdc_only—— 表是每次变更事件insert / update / delete的仅追加日志没有当前状态视图。both—— 同时保留一张合并后的当前状态表与一张独立的 CDC 日志表。最灵活但存储翻倍。需要提醒的是文档所述模式均以源码为准配置 CDC 前建议先用external-data-sources-check-cdc-prerequisites-create确认前置条件Postgres 逻辑复制、wal_levellogical、复制槽与发布对象、账号权限避免首次运行即失败。Webhook 是两步设置建源之外还要注册与其他同步类型不同webhook在建源之后还需要第二次 API 调用在支持 webhook 的表上以sync_type: webhook创建源。调用external-data-sources-create-webhook-create({id})向外部服务注册 webhook并创建处理入站事件的 HogFunction。跳过第 2 步webhook 类型的 schema 就会一直空转、没有任何数据流入。create-webhook实际完成的工作包括创建接收 webhook POST 的 HogFunction、构建外部事件类型到 PostHog schema id 的映射、调用源侧 API如 Stripe注册 webhook URL 并订阅相关事件且在 Stripe 上会自动捕获signing_secret并安全存储流程见 SKILL.md 的 Step 6。如果外部服务不允许 PostHog 自动注册通常是所存 API key 缺少 webhook 权限则回退到手动设置在源的控制台注册 webhook然后通过external-data-sources-update-webhook-inputs-create提交签名密钥signing secret。这种情况下 HogFunction 仍会被创建只是处于禁用状态提交密钥后即可启用。两个重要细节调用前先查重调用external-data-sources-webhook-info-retrieve({id})若已返回exists: true就不要再调create-webhook——每次成功调用都会注册一个新的外部端点导致重复投递。WebhookSource是源码事实只有实现了WebhookSource接口的源类型才支持sync_type: webhook目前只有 Stripe。db-schema 响应中每个表的supports_webhooks标记才是可用性的唯一事实来源不要对 Hubspot、Salesforce、Postgres 承诺 webhook——它们走轮询同步详见 SKILL.md 的 Important notes。webhook 是批量同步的补充而非替代webhook 类型 schema 的首次加载仍通过轮询完成initial_sync_complete翻转为true后切换为推送之后 webhook 成为主要摄入路径同时保留sync_frequency周期性地做一次批量对账兜底——这是预期行为不是需要修复的问题。Sync frequency与sync_type正交的调度频率sync_frequency是 per-schema 的独立选项与sync_type正交。合法值由小到大为5min、15min、30min、1hour、6hour、12hour、24hour、7day、30day、never。5min是所有同步类型的下限——API 会拒绝更快的频率。不同场景的推荐值full_refresh非平凡大小表默认24hour——每次运行都重新导入全表低于小时级的频率通常只是浪费。incremental/append合理大小表上1hour或6hour是合理默认。5min下限存在但很少需要——用户若追求实时优先推荐cdc或webhook。cdc频率基本不适用——CDC 是持续流式同步。冷归档表7day或30day保持调度存活、避免浪费运行。never值会冻结 schema——不再自动同步但仍可通过external-data-schemas-reload手动触发。在源码层面频率以sync_frequency_intervalDurationField默认 6 小时和sync_time_of_dayUTC 时分持久化见 external_data_schema.pyMCP 工具external-data-sources-update-schema也支持更新频率与 UTC 时段见 tools.yaml。一份可复用的配置示例结合上面的规则一个 Postgres 源的schemas数组可以这样组织完整示例见 SKILL.md 的 Step 5{ 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], sync_frequency: 1hour }, { name: users, should_sync: true, sync_type: full_refresh, sync_frequency: 24hour }, { name: audit_log, should_sync: false } ] } }schemas数组的约束db-schema 返回的每张表都应出现在数组中不想同步的置should_sync: falsesync_type仅在should_sync: true时必填incremental_field/incremental_field_type在sync_type为incremental或append时必须提供primary_key_columns在sync_type为cdc时必须提供。若其中任何一张表使用了sync_type: webhook建源后务必补上create-webhook这第二步。小结同步类型的选择本质上是成本、新鲜度、数据形态三角的权衡full_refresh最简单但每次全量重导incremental/append用水位线控制成本、适合大多数轮询场景cdc用逻辑复制换取亚分钟级新鲜度代价是主键与 Postgres 前置条件webhook提供真正的实时推送但只在实现WebhookSource的源当前为 Stripe上可用且需要单独的注册步骤。配置前以db-schema响应中的能力标记和候选字段为准配置后以external-data-schemas-list观察每张表的同步状态即可稳定落地一套贴合数据形态的同步方案。【免费下载链接】posthog:hedgehog: PostHog is the leading platform for building self-driving products. Our developer tools – AI observability, analytics, session replay, flags, experiments, error tracking, logs, and more – capture all the context agents need to diagnose problems, uncover opportunities, and ship fixes. Steer it all from Slack, web, desktop, or the MCP.项目地址: https://gitcode.com/GitHub_Trending/po/posthog创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
代码包深度解析与实践指南)
