PostgreSQL 的不足：（当然优点也很多）

（1）最新版本和历史版本不分离存储，导致清理老旧版本时需要做更多的扫描，代价比较大但一般的数据库都有高峰期，如果合理安排VACUUM，这也不是很大的问题，而且在PostgreSQL9.0中VACUUM进一步被加强了。

（2）在PostgreSQL中，由于索引完全没有版本信息，不能实现Coverage index scan，即查询只扫描索引，不能直接从索引中返回所需的属性，还需要访问表，而Oracle与Innodb则可以。

（3）对于简单而繁重的读取操作,超过了PostgreSQL的杀伤力，可能会出现比同行（如MySQL）更低的性能。

（4）按给出的该工具的性质，从普及度来说它还缺乏足够后台支撑，尽管有大量的部署——这可能会影响能够获得支持的容易程度。

在PostgreSQL中，由于索引完全没有版本信息，不能实现Coverage index scan，即查询只扫描索引，不能直接从索引中返回所需的属性，还需要访问表，而Oracle与Innodb则可以。

• 它在性能方面比 MySQL 慢。
• 与 MySQL 相比，它不支持许多开源应用程序。
• 由于更加注重兼容性，为提高速度而进行的修改需要额外的工作

灾难性的XID解决方案

关于这一点建议你查看更多资料，毫不避讳地说，这个缺点真的很让人头疼。 该问题导致过很多长时间停机的故障，长达数天。 如果你查看足够的材料，比如用Google搜索，就会发现许多人都在这个功能上踩雷。 几乎所有不具备高级专家经验的PostgreSQL技术人员，都会遇到这个问题。

或许将来某个时候，XID可能会过渡为使用64位整数，但是在那之前，我们仍然要继续应对这个挑战。 不过好一点的是，与飞机上的应用软件不同，这个故障我们是可以尽量去避免的，只要不使用这个功能的话。

灾难性的XID解决方案
failover故障可能会丢失数据
低效率的复制会传播失败
MVCC垃圾回收频发
每次连接处理=规模化痛苦
主键索引简直是浪费空间

PG现在势头挺猛的，dbengine排名第四，且一直保持增长；

国内好多数据库（部分云数据库、金仓、瀚高等）都是基于这个生态构建自己的产品；

好几个新的htap数据库都基于pg生态，如google的alloydb；

pg在单机性能及数据库引擎方面做的比较好，业界说法是最先进，最接近oracle的开源数据库。

缺点：

发力和占据市场晚，市场基数不够大；

生态弱；

扩展性这块不够看，插件和列存不够强；

其他的xid，mvcc等技术有痛点，但没有完美的产品，是不是不可以克服。

PostgreSQL为每个连接生成一个进程，而其他大多数数据库都使用更有效的连接并发模型。 由于存在一个相对较低的阈值，在该阈值上添加更多的连接会降低性能（约2个内核），最终会导致性能下降，而性能下降的比例可能会很高（难以估计，高度依赖于工作负载），就会使得性能调优的难度增加。