很多朋友都说有开源的PG、MySQL，把它用好不就行了，为啥还要有那么多数据库厂商去重复造轮子呢。这其实不是一个技术问题，而是一个哲学问题。从不同的角度去看它，会有截然不同的答案。也无所谓谁对谁错，重复造轮子的，如果造出来的轮子更适合你的车子，那就是成功的，否则就是白花钱了。

说实在的，用要不要重复造轮子来看要不要自研数据库，要不要基于开源数据库代码自研数据库这个问题，本身就不够贴切。轮子的规格、用途、性能大体上已经被汽车制造商研究得十分透彻了，什么样的车要配什么样的轮子，不仅汽车制造商清楚，轮胎制造商可能更是门清。

在数据库领域，一些像轮子一样的标准化组件确实没必要自己开发，连Oracle都会直接使用openSSL的开源代码，没去自己开发自己的SSL模块，这些标准化的组件与自己的数据库产品整合起来十分方便。不过对于存储引擎和SQL引擎等数据库核心组件，以前比较成功的商用数据库厂商都是自己干的。与现在的大多数新锐数据库计算存储解耦的设计思想不同的是，O记的SQL引擎与存储引擎是强耦合的，这虽然让Oracle增加新的存储引擎的时候会比较费劲，不过确保了SQL引擎的强大能力。

不重复造轮子，直接基于开源的数据库产品-比如PostgreSQL去封装商用数据库产品，加入自己的特性能力，合并PG的各种补丁，这种做法可以节约数据库产品研发的成本，将有限的资金集中在自己所擅长的领域上。EDB和PostgreSQLPro就是这样的企业，它们和红帽一样都是开源下游企业。同时他们的数据库核心研发人员也积极地对社区代码做出贡献，形成良好的伴生生态。这种企业可以把公司的业务重点放在一些核心技术研发和售后服务上，可以在公司规模不大的情况下获得较大的市场。不过有利必有弊，这样的数据库公司的内核必须依赖社区版代码，其技术发展的方向只能和社区版契合。而社区版的数据库产品受限于整个开源社区的管理团队和代码贡献者，在某些技术领域可能会受到一定的限制。因此此类企业必须紧跟社区版的最新代码，跟着社区升级自己的产品，在某些高级特性的研发上必然受限。

崖山数据库的存储引擎为了实现类似Oracle RAC的功能，他们必须首先对存储引擎进行深度的改写，从而能够实现类似PI/CR/CURRENT BLOCK的机制，从而实现类似 Oracle GCS/GES的功能。没有页级UNDO，会导致跨节点一致性读在页数据交换上的开销放大，全局热块会最终让RAC下的并发访问性能下降数个等级。

实际上很多以PG为基础研发数据库产品的企业都尝试过做类似Oracle RAC的功能，不过都无一例外地失败了，PG的ASTORE存储引擎的问题其实是个关键。如果不把存储引擎这个轮子彻底重构了，基于PG的数据库厂商就无法真正的做出类似Oracle RAC的东西出来。基于此，在开源代码的基础上，重新设计一些轮子替换掉原来的代码，虽然从此与开源社区基本上脱离，需要自己独立发展，但是获得的收益可能是更大的。

看到这里有些朋友会说，PG不就够好了，为啥还要去折腾这些吃力不讨好的功能呢?可能不同的人看问题的角度不同吧，PG虽然很优秀 ，但是离一个真正的企业级数据库还有不小的距离，去年好像我也写过一篇关于PG离企业级数据库还有多远的文章。如果你的企业是一个奉行长期主义的，希望做出一款真正的企业级数据库，你的出发地可以是开源代码，但是脱离社区的自研恐怕还是必须的。因为跟随社区代码，你的产品的上限是受限的。

2016年的贵阳数博会期间，我和时任易鲸捷CTO的丁宏博士有过一次交流，当时我们正在合作对电网的一个高并发的复杂业务场景进行数据库产品适配的测试。从测试的效果来看，想要继续突破已经有些困难了。丁总当时说他早就发现了存储引擎已经成为了自己产品未来发展的瓶颈点，想要让产品能够向一个高效率、高性能、具有通用数据库特征的分布式数据库发展，必须为SQL引擎的未来重构存储引擎。不过因为投资巨大，在公司内争议颇多，他目前的想法暂时还无法付诸实现。

想要做好一个数据库产品，不断满足复杂的企业级用户的各种古怪的需求，不断冲击更高的技术门槛，形成真正意义上的技术优势，躺在开源代码身上还是不够的，自己造一些特殊规格的轮子在所难免。

每个用户对数据库的需求不同，每个企业对数据库产品的追求不同，因此对这个问题有不同的看法也很正常。我们作为外行的看客，也只能看个热闹而已，数据库企业都有自己的初衷和苦衷，对于他们的选择，多鼓励，少挖苦吧。