Postgres适用于一切,这靠谱吗?

3作者: saisrirampur大约 1 个月前原帖
我最近重新阅读了一个关于“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 用于一切”要更好。
查看原文
I recently revisited an HN discussion on using “Postgres for everything” (https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=42347606 ) and also read&#x2F;participated in this Twitter thread: https:&#x2F;&#x2F;x.com&#x2F;BenjDicken&#x2F;status&#x2F;2002742633966514544 . Both prompted a few reflections. What stood out to me was how divided opinions still are—some people strongly believe in this approach, while others don’t. I wanted to share my perspective on this.<p>In my experience, many proponents of “Postgres for everything” haven’t been exposed enough to (newer) purpose-built technologies and the tremendous value they can create. I was firmly in that camp for nearly a decade while working at Citus and on the Microsoft Postgres team. After building PeerDB (a Postgres CDC product that syncs data to various systems) and working at ClickHouse, my perspective completely changed. Seeing firsthand the “magic” that purpose-built systems deliver for their specific use cases—especially in terms of cost, performance, and scale—was truly eye-opening.<p>Don’t get me wrong—I’m a huge Postgres proponent and have spent 10 years helping customers implement it. However, I strongly believe in using Postgres for what it was designed for in the first place. Postgres is a row-based OLTP database, with over 30 years of engineering effort dedicated to making it robust for that specific workload.<p>Proponents of “Postgres for everything” often argue that a single stack is simpler and reduces complexity. What’s frequently overlooked, however, is the CAPEX and OPEX required to make Postgres work well for use cases it wasn’t designed for. At Citus, many customers had reasonably sized teams of Postgres experts whose primary job was to constantly tune, operate, and “babysit” the system to keep it working at scale.<p>Separately, we’re seeing the need for purpose-built technologies emerge much earlier in a company’s lifecycle, likely driven by AI. At ClickHouse, many customers using Postgres CDC are seed-stage companies that have grown rapidly. We pulled together some data that highlights these trends here: https:&#x2F;&#x2F;clickhouse.com&#x2F;blog&#x2F;postgres-cdc-year-in-review-2025#use-cases<p>Ultimately, I believe it’s better to make it seamless and even magical for users to integrate purpose-built technologies with Postgres, rather than making an overgeneralized claim of “Postgres for everything.”