自建 PostgreSQL 该不该用：先看它解决的问题是不是你的问题

shared_buffers 给到内存 25% 就够，再大收益递减，还要给系统留页缓存

它擅长的是业务主库；如果你只是自建服务的后端，用现成的东西更省事。

先说结论

自建数据库的难点不在装，在备份能不能恢复、膨胀有没有人看

• 适合：业务主库
• 不适合：数据分析只读库
• 学习成本：每个连接是独立进程，100 个连接光内存就要 0.5-1GB，应用侧必须用连接池
• 最大收益：pg_dump 是逻辑备份，只能恢复到导出那一刻，要 PITR 必须开 WAL 归档
• 最大风险：max_connections 调到 500 救急，内存被连接吃光

它到底解决什么

shared_buffers 给到内存 25% 就够，再大收益递减，还要给系统留页缓存。

换句话说，它把「业务主库」这件事从手工变成可重复的流程。这是它真正的价值，而不是功能列表的长度。

什么时候不该用

下面三种情况，用了反而更累：

max_connections 调到 500 救急，内存被连接吃光

只做 pg_dump 不做 WAL 归档，误删表只能恢复到昨天

长事务挂在连接池里，表膨胀到三倍还不知道

和替代方案比

autovacuum 触发阈值是 50 加 0.2 倍行数，千万行表要单独调。

这台工具的关键细节

几个决定长期体验的点：

• 每个连接是独立进程，100 个连接光内存就要 0.5-1GB，应用侧必须用连接池
• pg_dump 是逻辑备份，只能恢复到导出那一刻，要 PITR 必须开 WAL 归档
• autovacuum 触发阈值是 50 加 0.2 倍行数，千万行表要单独调
• 长事务会阻止 vacuum 回收，pg_stat_activity 的 xact_start 是排查入口

我的建议

自建数据库的难点不在装，在备份能不能恢复、膨胀有没有人看。

先用两周，跑一个真实的小任务；两周后你还想用它，再谈长期。

还有几处容易忽略的

都是小地方，但出问题时往往就卡在这里。

• 主版本升级不能直接换二进制，要用 pg_upgrade 或逻辑复制

工具是解法，不是身份。