华为真正想做数据库，把数据库作为一个完整的产品来做，其实是始于2011年底。当时，华为成立了2012实验室，也有了高斯实验室和Gauss DB。
就在这年，华为同时启动了面向OLAP数据库的研发预演，并足足用了3年的时间来预演代码和验证架构的可行性。研发团队分析了业界数据库相关理论和技术，在基于传统关系型数据库的SQL引擎和事务强一致性等基础上，进行了分布式、并行计算的改造。2014年，孵化出GaussOLAP数据库第一个产品版本。
2015年，华为与工商银行一起联合创新，Gauss OLAP数据库也开始在工商银行内上线，并逐渐取代某国外品牌数据仓库。从一开始的十几个节点到现在的单个集群超过二百个节点，这大概是目前国内数据仓库中最大的。事实上GaussOLAP数据库的产品交付过程也并非一帆风顺，也是经历了诸多磨难，尤其是在MPP大规模通信上踩过不少坑。
“最初，Gauss OLAP数据库采用的是SCTP通信协议。当时，工商银行的EDW数据仓库已经有上百个节点，再往上扩容，通信就面临很大的挑战”，Gauss OLAP数据库的一位核心研发工程师说。
因为，研发团队在实验室测试发现，随着集群的扩大，SCTP协议存在BUG，问题严重，一方面是稳定性，通信变得很不稳定，丢包严重；其次是性能，在大压力下，性能变得非常不稳定，而且存储空间已经达到70%了，照这样下去， 再有几个月集群空间肯定就不够用了，业务就会停摆责任之大，谁也承担不起。怎么办？
经过与客户沟通，工商银行要求华为GaussOLAP数据库团队必须尽快扩容一倍以上的节点。
此时，整个研发团队的压力可想而知，团队内部经过了无数次激烈的讨论后，最终决定采用自研的多流代理通信技术重构解决该问题。而这一重构，前后就花了半年多时间，最终扩容成功，确保了工商银行业务的稳定运行。
这样的故事，在Gauss OLAP数据库产品化的过程中不胜枚举。“没有以客户为中心的理念，没有像工商银行这样优质客户的积极反馈与配合，就不会有今天成熟可靠的Gauss OLAP数据库”，这位工程师说。
而在内核研发过程中，对研发团队而言，最大的痛苦莫过于完全无法预知外部客户会怎样去使用GaussDB，客户并不会像内部客户严格按照规范来，因此，当出现问题时，定位问题、复现问题就显得尤为重要，因为，只有定位到问题才能对症下药，如果连故障原因都找不到，解决问题也就无从谈起。
华为在数据库内核构建中，有着非常严格的要求，一旦发现的问题被解决后，一定要复盘，解决问题一定是经过严格推导出来的，如果问题解决过程含糊不清，或稀里糊涂地把问题解决了，这在华为是绝对不行的。
在所有测试中发现的问题，规范要求都必须要放入CI（数据库用例全集）里，这样CI就会被不断补充。“CI就像一道‘门禁’，数据库每一个版本的发布，必须要通过十年所积累的所有用例，只要一个没通过，就甭想发布。”
让工程师们印象最为深刻的是一次定位分布式事务一致性问题， 各种DDL, DML 高并发执行， 每隔几分钟，随机Kill 数据节点进程，验证实时校验数据的一致性长期稳定运行。
开始一切正常，但就在第17天的时候，测试发现有瞬间数据不一致问题，Log里并没有足够定位信息，也无法复现，定位了好几天没有进展，存储引擎团队的核心开发人员都很沮丧。
于是团队自行封闭会议，开始对MVCC机制，CSN可见性判断逻辑, Prune清理记录历史版本的逻辑做了逐行代码排查分析，结合Log, 模拟并行执行的时序，最终找到了根因，Prune记录的历史版本过早导致的问题。
也正是基于此，促使Gauss OLAP数据库团队开始思考并发场景测试方法如何才能更有效，因为是并发时序问题，出问题的时间窗口是很难卡到的，要在代码里模拟触发随机异常且控制其他线程的时序，才能让测试覆盖更全面，而这种测试方法帮助研发团队发现和解决了很多问题。
2017年，华为又启动了面向事务和分析混合处理的数据库研发。2018年，Gauss HATP数据库问世，并成功落地中国民生银行。据悉，民生银行采用了GaussDB分布式数据库+ARM服务器的全栈解决方案，从数据库层面解决了可扩展性问题，降低了应用分布式改造的难度，已应用于一卡通、贵金属模拟交易等交易类系统，是国产数据库在银行交易类系统的首次商用。
