零停机 Postgres 升级
工程师们剖析了一次在 AWS 上对大型 PostgreSQL 数据库进行实际升级、并尽量实现用户无感停机的尝试，这一过程依赖逻辑复制、应用双连以及精细的切换编排。评论者则争论这种复杂性是否值得，还是应该接受一次短暂的计划内停机——争点包括可用性与一致性的权衡、运维简单性与专用工具之间的取舍，以及客户究竟应当对可靠性抱有多高的预期。讨论还提到了 AWS blue/green 部署、基于 snapshot 的方案，以及把 Postgres 作为通用底座还是引入更专门服务的不同策略。
托管方案 vs 自定义流程
- 有人指出 Heroku 和 AWS 已经支持扩容和 follower 数据库，但也有人澄清，在繁忙的 DB 上 follower 可能严重滞后，而备份/副本也可能变慢或卡住。
- Aurora 新一些的小版本升级和 blue/green 功能受到称赞，但其支持取决于引擎版本，而且有人反馈体验不稳定，所以目前还不能被普遍信任。
多久升级一次，以及一次升多远
- 讨论集中在“big-bang”升级和频繁小升级之间的取舍。
- 一方观点：每次大版本升级的可用性风险都差不多，因此拖延只是在堆积工作量；一次跨很多版本升级会增加风险。
- 另一方观点：“如果没坏，就别修”再加上真实停机成本，导致团队通常会等到最后，然后投入大量精力做一个稳健的一次性流程。
Postgres 作为核心基础设施
- 批评意见认为：把一个 RDBMS 什么都拿来做（日志、队列、调度、业务数据）会形成单点故障，并把这项技术推到了其初衷之外。
- 反驳意见是：很多成功系统都是“Postgres/MySQL + Redis”；更少的组件和一个大家都熟悉的系统，可能比很多专门服务更好。
- 也有人强调这更像工程问题，而不是纯 CS：先把负载尽量收敛到 Postgres，等它不再适合时，再把日志之类的工作负载拆到其他系统中。
零停机 vs 可接受停机
- 对真正的零停机是否值得，分歧非常大。
- 很多人认为，短暂、提前公告的维护窗口（例如每隔几年停 10–15 分钟）对几乎所有 SaaS 都足够，而且比复杂的“零停机”工程更便宜。
- 另一些人，尤其是面向全球客户或基础设施客户的团队，认为任何故障都等同于他们客户的故障，并会损害信任或竞争力。
- 也有人强调，与其追求 100% 可用性，不如重视一致性和清晰沟通，并指出连医院和 hyperscalers 也接受计划内停机。
迁移技术与风险
- 讨论到的方法包括：
- 按表做逻辑复制（更安全，但繁琐且 IO 开销大）。
- 通过 snapshot + replication slot + 推进 LSN 快速创建逻辑副本；但有专家提醒这里存在微妙的数据损坏/丢失风险以及逻辑复制 bug。
- pglogical、自定义工具（例如 pg_easy_replicate）以及 GitLab/Instacart 风格的零停机切换。
- 大表挑战、sequence 同步，以及 ID 策略（UUIDv4/v7、KSUID、HiLo）是反复出现的主题。
- 还有不少人强调演练、验证（checksum、canary）以及至少要有概念上的回滚路径，即使它并不完全对称。