昨天一个老客户打电话来，说他们准备把核心业务从Oracle迁到PostgreSQL，让我帮忙评估一下。我打开他们发给我的表结构文档，看到那个快二十岁的PL/SQL包，里面塞满了动态SQL和隐藏的用户自定义函数，我突然笑了。这不是我第一次经历这种所谓的“去Oracle”运动，但我很清楚，三个月后他们会再找回我，说“我们还是继续用Oracle吧，只是能不能少收点服务费？”
先说说我自己的经历。2017年的时候，我曾经也信了那些技术大V的鬼话，觉得PostgreSQL天下无敌，性能好、开源、还没有那该死的授权费。当时正好有个项目要新上系统，我硬是说服老板用了PGSQL。刚开始确实爽，部署简单，连hot standby都容易配置。但到了真正处理高并发下的一致性事务时，问题就来了——不是性能差，而是你需要花大量时间去调参、去理解快照隔离的行为，而Oracle的Read Committed在绝大多数场景下就是无脑好用。还有那些存储过程，在Oracle里写惯了自治事务和管道函数的人，到了PG里就像失去了一条胳膊。我说这些其实没用，因为真正让客户崩溃的是后续的运维——PG的监控告警、日志分析、维护工具链哪比得上Oracle那一套成熟的东西？Oracle Enterprise Manager虽然丑，但人家真的把SQL调优、ADDM、AWR全整合起来了，出了问题你只需要点几下，就能告诉你该建索引还是要改SQL。
说到这，就不得不提Oracle的许可和维护费了。这可能是全世界DBA最痛恨的东西，包括我。每次看到客户为了一份“标准版”的合同付上百万人民币，我都觉得Oracle这帮人简直是强盗。可你反过来想，正是这笔巨额的授权费用，支撑起了Oracle数据库的稳定性神话——他们有钱养一支庞大的研发团队，有钱把每一个bug都修到极致，有钱在Exadata上堆硬核。有些产品之所以便宜，是因为它把风险和成本转嫁给了你和你那本就不够用的运维团队。我见过太多企业为了省两份Oracle许可费，却花三倍的钱去招四个PG运维开发，到头来系统一上线就出各种性能事故，客户才明白什么叫“免费的是最贵的”。
但我也不是完全没长进。经过了那次痛苦的迁移，我确实对Oracle有了更深的“偏见”——比如它的RAC在云环境里就是个怪物，你在AWS里搭一台两节点的RAC，网络延迟分分钟教你做人。还有它那又臭又长的官方文档，经常这个文档说不能这么做，另一个文档又说可以，最后你得抽签决定信哪个。可是你要让我推荐一个真正能支撑起银行核心或制造ERP的系统，我脑海里第一个蹦出来的还是Oracle。不是因为它完美，而是因为它那些所谓的“过时”设计，比如block-level的redo日志、shared pool的shared everything架构，恰恰在最苛刻的场景下稳如老狗。反观那些新一代分布式数据库，热闹是热闹，可你真的敢把钱压在它们查个分区还要担心脑裂吗？
所以我现在给客户的建议都变了：别抱着“推翻Oracle”的心态，而是要把它当成一个中年老将——他确实贵、确实傲慢、确实不听人话，但关键时刻他真能给你扛事。你唯一要做的，是好好设计你的应用层，别把所有逻辑都用存储过程死绑在数据库里，那样以后就算是Oracle换了马甲你也跑不掉。诚然，云原生是趋势，但趋势不等于正确，更不等于适合你的业务。Oracle输给的不是PostgreSQL，也不是什么号称“秒杀”的国产数据库，而是输给了这个时代对成本的极致压缩和人才向应用层的转移。于我而言，也许再有两年我也要去转向云运维了，但只要还有客户打电话来问我要不要迁移，我依然会先问他一句：“你们的业务，配得上Oracle的傲慢吗？”
