Supabase中Stripe Sync Engine与应用专属元数据架构咨询

场景背景 #

我通过Supabase仪表盘安装了Stripe Sync Engine，此前已在新项目中创建public.products、public.prices、public.audience_bands三张表。Stripe Sync Engine自动生成了stripe架构及相关计费表（如stripe.products、stripe.prices），现在存在两套独立数据源：

• public.products：包含stripe_product_id、location_id等字段
• public.prices：包含price_id、credits等字段（credits为核心业务字段，关联用户权益、产品筛选及后台配置）
• public.audience_bands：包含audience_label、max_age等字段
• stripe.products/stripe.prices：作为计费核心事实源，存储unit_amount、currency等计费数据，不适合存放应用专属字段

以下针对架构疑问逐一解答：

问题解答 #

1. 是否应同时维护public.products/public.prices与stripe.products/stripe.prices？ #

必须保留双表架构。两者职责完全分离：

• stripe架构下的表是计费事实的唯一可信源，由Stripe Sync Engine自动同步，不能手动修改，确保计费数据和Stripe平台完全一致
• public架构下的表是应用业务逻辑的载体，存放和业务强绑定的专属字段（比如location_id、credits），完全由业务方控制，避免计费逻辑和业务逻辑耦合

2. 若保留双表，是否推荐通过触发器将stripe.*数据同步至public.*，应用仅查询public.*？ #

不推荐用触发器单向同步。原因如下：

• stripe表的数据由Sync Engine自动维护，触发器同步会造成数据冗余，增加数据库负载
• Stripe侧的字段变更（比如新增状态字段）会触发同步，可能引发public表的数据一致性问题
• 更合理的方式是：应用查询时通过关联字段（stripe_product_id、price_id）将public表和stripe表JOIN查询，既保证数据实时性，又避免冗余

3. 或是否应避免数据冗余，将应用专属字段存入Stripe元数据，直接查询stripe.prices并创建RLS策略？ #

不建议这么做，Stripe元数据存在明显局限性：

• 元数据是键值对结构，不支持复杂查询（比如范围筛选credits<=8），查询效率极低
• 元数据无数据类型约束，容易出现格式错误（比如credits存成字符串而非数字）
• 无法和public.audience_bands这类业务表做关联查询
• stripe表由Sync Engine自动生成，结构可能随Stripe API更新变化，维护RLS策略成本更高

4. 若仅用元数据，如何高效实现location_id=X的活跃产品筛选、credits<=8的价格筛选等查询？ #

如果非要用元数据，只能通过两种方式勉强实现，但体验远不如双表架构：

1. 先通过Stripe API筛选（比如用metadata[location_id]=X过滤产品），再同步到Supabase，但会失去Supabase的查询灵活性
2. 在Supabase的stripe.prices表上给metadata字段创建JSONB索引，提升查询效率，示例代码：

CREATE INDEX idx_stripe_prices_metadata_credits ON stripe.prices USING GIN ((metadata->>'credits')::int);

但这种方式依然不如将credits存为public.prices的单独列方便，且数据类型校验全靠手动维护，容易出错

5. 触发器是否为合理的同步方案，是否有更标准的架构分离Stripe计费状态与应用业务逻辑状态？ #

触发器不是合理的同步方案，标准架构应为职责分离的双表关联架构：

• stripe架构：仅作为Stripe数据的镜像，完全由Sync Engine管理，不做任何手动修改，确保计费数据准确一致
• public架构：存放应用专属业务字段，通过外键（比如stripe_product_id关联stripe.products.id）和stripe表建立关联
• 应用层查询时，通过JOIN关联两张表获取完整数据；业务逻辑只修改public表字段，计费操作直接调用Stripe API，由Sync Engine自动同步stripe表数据

这种架构既分离了计费和业务逻辑，又保证了数据一致性与查询效率。

补充：stripe.subscriptions与public.subscriptions的架构建议 #

和产品/价格的逻辑完全一致：

• 保留stripe.subscriptions作为订阅计费状态的唯一可信源，存储Stripe侧的订阅数据（比如status、current_period_end等）
• 创建public.subscriptions表，存放应用专属的订阅业务字段（比如用户权益生效规则、关联audience_band_id等），通过stripe_subscription_id关联stripe.subscriptions.id
• 应用查询订阅时关联两张表获取完整信息；业务逻辑仅操作public.subscriptions的业务字段，订阅的创建/更新/取消通过Stripe API完成，由Sync Engine同步stripe.subscriptions数据

内容的提问来源于stack exchange，提问作者Andreul-