基于AWS服务的Debezium替代方案：实现Postgres变更捕获推送至SQS

以下方案均为AWS全托管/半托管能力，不需要维护额外的开源组件：

方案1：AWS DMS（数据库迁移服务）直接投递到SQS（最贴合需求的通用方案） #

这个是官方支持的CDC场景标准方案，全托管免运维：

• 前置配置：给PostgreSQL实例（支持RDS PostgreSQL、Aurora PostgreSQL、自托管PostgreSQL）开启逻辑复制，将参数wal_level设为logical，为DMS账号授予逻辑复制权限
• 配置流程：
  1. DMS控制台创建PostgreSQL源端点，填写数据库连接信息
  2. DMS控制台创建SQS目标端点，填写目标SQS队列ARN，配置DMS向SQS发消息的IAM权限
  3. 创建CDC复制任务，可选「全量同步+持续增量」或「仅增量捕获」，开启变更数据捕获开关
• 特性：默认输出JSON格式的变更消息，支持自定义字段映射、操作类型过滤，可捕获INSERT/UPDATE/DELETE的前后镜像数据，端到端延迟秒级，适合绝大多数生产场景

方案2：EventBridge Pipes 流转变更（轻量场景首选） #

如果你的流量规模不大，不想配置复杂的DMS任务，用这个方案配置成本最低：

• 直接把PostgreSQL逻辑复制流作为EventBridge Pipes的源，Pipes会自动完成WAL日志拉取、解析逻辑
• 无需额外写代码，在控制台配置流转规则、字段转换规则后，直接设置目标为SQS队列即可
• 按调用量计费，无常驻资源成本，延迟在百毫秒到秒级，适合中小流量的CDC场景

方案3：自定义逻辑复制消费（适合需要深度定制的场景） #

如果你需要对变更消息做复杂的清洗、过滤逻辑，可以用这个方案：

• 在PostgreSQL中创建逻辑复制槽，用wal2json或pgoutput插件解码WAL日志
• 用Lambda定时拉取复制槽的变更数据，自定义加工成需要的格式后直接推送至SQS
• 优势是完全可控，可灵活实现自定义规则，成本比DMS更低，适合小流量、有定制需求的场景
• 注意需要自行管理复制槽水位，避免WAL日志堆积占满数据库存储，同时自行实现消息去重、重试逻辑

• SQS单条消息最大支持256KB，如果你有单行数据大小超过该阈值的场景，建议将完整变更数据存到S3，SQS仅投递S3对象引用
• 若要求消息严格有序，选择SQS FIFO队列作为目标，同时配置CDC任务按主键分区，避免消息乱序
• 所有方案都要求PostgreSQL开启逻辑复制，RDS/Aurora实例修改wal_level参数后需要重启生效

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