这条 Show HN 介绍了 Streambed：一个把 Postgres 的 WAL 通过 logical replication 直接流到 S3 上的 Apache Iceberg（面向数据湖的开放表格式）里的工具，并用嵌入式 DuckDB（轻量分析引擎）让它还能通过 psql 查询。作者说自己曾是 Cloudflare（大型网络基础设施公司）Postgres 团队的技术负责人，起因是 BI 和 dashboard 团队需要跑长查询，传统做法不是再开一份 read replica，就是把数据 ETL 到别的分析库里。评论区把它放进更大的 ELT/CDC 讨论中：有人提到 pg_lake、DuckLake、Debezium、ingestr 和 AWS Zero ETL 等替代方案，也有人提醒真正做分析通常仍然需要数据转换、分层和建模。
不少人把 Streambed 和 pg_lake、DuckLake、Debezium + Iceberg + DuckDB 这类方案放在一起比较。有人说 pg_lake 的 pushdown 能力不足，跑 OLAP 查询会变贵；也有人因为 DuckLake 需要脱离 PG-first 工作流而放弃。尽管如此，大家对“把 Postgres append-only 表直接送到 Iceberg on S3”这个方向很感兴趣，表示会去试，并把它看成同一赛道里的新选择。
作者解释这套方案来自 Cloudflare 内部的真实需求：BI 和 dashboard 团队需要跑长分析查询，而现成做法通常是再加一层 read replica，或者先 ETL 到分析数据库。Streambed 的目标是尽量少组件，所以直接作为 Postgres 的 logical replication subscriber，抓 WAL 变更后写入 Iceberg on S3，再通过嵌入式 DuckDB 提供查询。作者也承认这条链路有很多 edge cases，目前还很早期。
有人指出，把 WAL 可靠地复制到 S3 和 Iceberg 本身就已经很难，但这并不等于不需要 ETL。更准确地说，这类方案更像 ELT：先把数据落到分析存储里，再按真实业务需要做转换、分层、索引和 schema 设计。评论里还提到 AWS Zero ETL、variant type 和 schema-on-read 能降低门槛，但真正想做靠谱分析平台，后续的数据工程工作并不会消失。
围绕 Postgres-compatible 查询接口，讨论重点其实不是“必须用 psql”，而是 BI 和 dashboard 团队能否像查 Postgres replica 一样直接查分析数据。也有人认为如果已经采用 Iceberg，通常本来就有其他 query engine，所以这个接口更像是调试或兼容层；作者则补充说这是为了满足既有 Postgres 工作流。与此同时，评论区还追问 CDC 在 Go 里的可靠实现、以及吞吐量和端到端延迟等性能指标，说明大家更关心这套链路能否在生产里稳定跑。
CDC: Change Data Capture，持续捕获数据库变更并同步到下游系统的技术。
WAL: Write-Ahead Log，Postgres 记录变更的写前日志，常用于恢复和复制。
logical replication: Postgres 的逻辑复制机制，可按行/事务流式传输变更数据。
Iceberg: Apache Iceberg，一种面向数据湖的开放表格式，适合大规模分析查询。
ELT: 先 Extract 和 Load，再在目标系统里 Transform 的数据处理流程。
DuckDB: 嵌入式分析型数据库，适合在本地或文件数据上直接跑 SQL 分析。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。