最新

我正在让Claude Opus 4.5尽可能多地制作HTML/JS应用程序——到目前为止已经超过100个。它的能力相当惊人，大多数应用程序都能一次性完成。

我最近重新阅读了一个关于“Postgres 用于一切”的 HN 讨论（https://news.ycombinator.com/item?id=42347606），并参与了这个 Twitter 话题（https://x.com/BenjDicken/status/2002742633966514544）。这两者让我产生了一些思考。让我印象深刻的是，大家的观点依然分歧很大——有些人坚信这种做法，而另一些人则持反对意见。我想分享一下我的看法。 根据我的经验，许多“Postgres 用于一切”的支持者并没有充分接触到（更新的）专用技术及其所能创造的巨大价值。在 Citus 和微软 Postgres 团队工作近十年，我曾坚定地支持这一观点。然而，在构建 PeerDB（一个将数据同步到各种系统的 Postgres CDC 产品）并在 ClickHouse 工作后，我的观点发生了彻底的改变。亲眼目睹专用系统为特定用例提供的“魔力”——尤其是在成本、性能和规模方面——让我大开眼界。 不要误解我的意思——我非常支持 Postgres，并且花了十年时间帮助客户实施它。然而，我坚信应该将 Postgres 用于其最初设计的目的。Postgres 是一个基于行的 OLTP 数据库，经过超过 30 年的工程努力，致力于使其在特定工作负载下保持稳健。 “Postgres 用于一切”的支持者常常辩称，单一技术栈更简单，能降低复杂性。然而，常常被忽视的是，为了使 Postgres 在其并未设计的用例中良好运作所需的资本支出（CAPEX）和运营支出（OPEX）。在 Citus，许多客户拥有合理规模的 Postgres 专家团队，他们的主要工作是不断调整、运营和“照看”系统，以保持其在大规模下的正常运作。 另外，我们看到专用技术的需求在公司生命周期的早期阶段就开始出现，这可能是受到人工智能的推动。在 ClickHouse，许多使用 Postgres CDC 的客户都是快速成长的种子阶段公司。我们整理了一些数据，突显了这些趋势，您可以在这里查看：https://clickhouse.com/blog/postgres-cdc-year-in-review-2025#use-cases 最终，我认为让用户无缝且甚至神奇地将专用技术与 Postgres 集成，比起泛泛而谈“Postgres 用于一切”要更好。