初创公司的 Postgres 求生指南
创业团队在分享运行 PostgreSQL 的“血泪史”时强调：监控、备份和连接池这些运维基础，比花哨调优更决定系统能否活下去。评论者围绕 AWS RDS 等托管服务与廉价 VPS 自托管展开争论，在成本、厂商锁定和高可用需求之间权衡，同时分享具体的备份工具、连接池策略以及 DIY 方案的局限。模式设计和查询模式也是重点话题，建议优先做好规范化而不是过度依赖 JSONB，谨慎对待长事务和锁，并真正理解索引、迁移和 ORM，才能在系统扩展时避免性能与可靠性问题。
备份、监控与“生存”基础
- 几位评论者认为这份指南低估了备份、恢复和监控的重要性。
- 很多人强烈认为，任何生产环境中的 Postgres 都需要：
- 自动备份（理想情况下是 PITR）以及定期的恢复测试。
- 对 XID wraparound、磁盘使用情况以及长事务进行监控，并且要通过告警而不是邮件进行通知。
- 提到的工具包括：pgBackRest（很受欢迎，支持 PITR、增量差异备份，但需要定期全量备份）、Barman、简单的
pg_dump+ cron + 对象存储，以及卷快照（例如 EBS）作为辅助手段。
托管式 vs 自托管 Postgres
- 许多人主张尽早使用托管服务（RDS/Cloud SQL），以获得 HA、备份、PITR 和更少的运维负担。
- 也有人反馈副本配置过度、成本膨胀，或者托管方案限制令人沮丧，并且容易被云厂商锁定。
- 还有人认为，配上几位 DBA 再自托管 Postgres（通常运行在便宜的 VPS 或 Hetzner 上）能提供更高的灵活性和更低的成本；基本的 HA 架构也可以用很低的费用来运行。
模式设计、规范化与 JSONB
- 大家普遍同意，良好的模式设计和规范化很重要；自动生成模式的 ORM 受到批评。
- JSONB 适合可变数据或日志类数据，但过度使用会损害性能和数据质量；规范化模式加上 join 通常已经足够快。
- 有人建议使用只追加的“事实来源”表，并通过派生的反规范化视图来使用；也有人警告，把事件溯源用到处处对初创公司来说过于夸张。
索引、UUID 与查询规划
- 讨论了索引类型：默认用 btree，但在合适的工作负载下，GIN/GiST、BRIN 和 hash 索引也很强大。
- 建议考虑使用 UUIDv7 而不是 UUIDv4，以获得更好的索引局部性；也有人指出 bigint serial 主键通常更简单，而且在 join 时更快。
- 关于查询规划器的怪癖：有时多个更简单的查询或内存中的 join，会比一个复杂查询表现更好；一些人会在测试中禁用 seqscan 来检查索引使用情况。
事务、锁与死锁
- 警告不要使用长时间运行或 idle-in-transaction 的会话；建议使用超时设置（
idle_in_transaction_session_timeout、lock_timeout、statement_timeout）。 - 为了避免死锁，应始终以一致的顺序对行和表加锁；重试机制可能会加剧热点行争用。
- 关于
SELECT … FOR UPDATE和SKIP LOCKED的争论：它们对队列和游戏很有用，但如果你的核心模型是只追加的，那就可能是一种代码异味。
连接池
- 连接数限制是初创公司常见的故障模式。
- 外部连接池器如 PgBouncer（LIFO）有助于减少数据库连接数，而进程内的 FIFO 池主要是降低延迟。
- 需要警惕按请求开启事务，以及依赖注入的连接保持事务开启时间过长。
存储函数与 ORM
- 观点分歧明显：有人认为存储过程在约束、触发器和安全方面很强大；也有人避免使用它们，以便把逻辑留在应用代码中并保持灵活性。
- ORM 也有类似分歧：有人把它们视为长期技术债，更偏好原生 SQL；也有人觉得它们很高效，只要你理解 SQL，并在需要时能下沉到更底层即可。