我们把客户数据仓库全部构建在 Postgres 上
完全基于 PostgreSQL 构建客户数据仓库——使用外部数据包装器和 `pg_cron` 等功能，而不是 Fivetran 或 BigQuery 之类的工具——承诺带来简单性和统一、熟悉的技术栈，但也引发了关于可扩展性和长期可维护性的质疑。评论者争论将多少业务逻辑和编排推进数据库内部，认为存储过程在测试、调试和重构方面的工具支持较弱，而外部 ETL/编排框架和列式仓库则更成熟。讨论还强调了面向 Postgres 平台的产品在清晰定位和透明定价方面的问题，这些平台试图取代更专门的分析栈。
Postgres 作为数据仓库 vs 专用数据仓库
- 一些人认为只用 Postgres 构建的“仓库”很有吸引力，因为它更简单、工具更少，尤其是在数据量不大的情况下。
- 另一些人则认为，与列式仓库（BigQuery、Snowflake、Redshift、ClickHouse）相比，Postgres “不适合分析扩展”，尤其是在大量聚合和长时间保留方面。
- 批评者指出，这种做法往往意味着只保留很短的数据窗口（例如 30 天），而许多业务会认为这远远不够，尤其是在列式存储已经很便宜的情况下。
- 讨论中提到了一些列式/分析扩展和项目（例如
pg_analytics、ParadeDB、S3-backed storage、类似 Neon 的架构），作为将 Postgres 扩展到仓库用例的方式。
数据库中的业务逻辑
- 一派观点是：“只把 Postgres 当作数据存储。” 避免在数据库内使用
pg_cron流水线、重度PL/pgSQL，或类似 Supabase 的 API/权限机制；这些东西难以测试、调试、重构，也不利于新工程师上手。 - 另一派则认为，设计良好的函数、触发器、行级安全和 PostgREST API 可以显著提升安全性并减少 bug，尤其是在访问控制和完整性约束方面。
- 有人提出“厂商锁定”的担忧，但也有人反驳说，依赖 Postgres 特有功能是值得的，因为它能带来性能和能力上的收益。
工具、测试与迁移
- 很多人抱怨数据库逻辑的易用性不足：与通用编程语言相比，IDE 支持、重构和文档生成都很有限。
- 也有人提到一些新兴工具：
postgres_lsp、DataGrip/JetBrains IDE、pgpkg、类似 skeema 的方法、PL/pgSQLlint 工具、测试框架、基于 Docker/Testcontainers 的集成测试，以及用于版本管理和测试 SQL 的 Liquibase/Flyway/dbt。 - 大家普遍同意，把 SQL 对象放在 Git 管理的文件中，并通过迁移工具或声明式工具部署，是保持清晰和可维护的关键。
外部数据包装器与数据迁移
- 一些人更喜欢用 FDW，而不是 Fivetran/Airbyte 之类的工具，因为前者更简单；但也有人报告说，在大型或复杂的跨数据库查询上会遇到严重性能问题，因此更倾向于 ETL 工具或中间层代码。
- 讨论中提到的实用 DW 模式包括：用于原子刷新（atomic refresh）的 schema swap、通过分块复制避免长时间锁定，以及使用外部调度器（cron/ECS）而不是
pg_cron。
定义、流处理与产品反馈
- 一些人认为文中描述的系统“只是一个数据库”或“客户使用指标系统”，并不算完整的数据仓库。
- 也有人对 Postgres 上的流式/持续查询很感兴趣（例如类似 Materialize 的行为、基于 Debezium 自己搭建、epsio.io），但目前的方案要么过重，要么不完整。
- 多位评论者批评 Tembo 的网站定位不清晰，价格信息深埋页面中，呼吁提供明显的定价页，以及更不打扰用户的兴趣收集方式（例如简单的 newsletter 表单）。