目前國產關係型數據庫已經有上百種，比較知名的也有好幾十種，其中大多數都和某些開源數據庫或者開源組件有關。實際上我並不反對國產數據庫基於開源代碼構建，因爲利用開源代碼可以縮短國產數據庫研發與上市的時間，縮短國產數據庫與國外商用數據庫的技術差距。數據庫是在應用中不斷磨合出來，而不是簡單的研發出來的。很多朋友喜歡講某某數據庫技術很先進，用了很多新技術。如果爲了滿足某個用戶的特殊應用場景需求而使用某些先進技術，這是沒有任何問題的，而對於數據庫產品來說並非如此。如果你看看Oracle數據庫就是可以看出其核心的很多核心技術甚至都是三十多年前就已經成型了，其技術優勢的來源是這些年不斷滿足用戶需求的功能迭代。
我們分析國產數據庫的源頭並不是爲了證明哪個數據庫是開源套殼的，因爲我並不反對國產數據庫擁抱開原生態，只要數據庫廠商在開源代碼上疊加了自己的技術和價值，哪怕只有簡單的服務，都是應該得到尊重的，數據庫產品的價值取決於數據庫廠商能夠給與用戶的價值。
上圖是2022年我們對部分國產數據庫的技術來源進行分析統計的結果，數據來源是截至與2021年7月的工信部白皮書。其中基於PG和Mysql兩大開源項目的國產數據庫產品接近60%。在我對國產數據庫的譜系分析的時候也看到，幾乎所有的國產數據庫廠家都在開源數據庫上進行了一定的研發改造，或者加入了自己的核心代碼。
一部分數據庫廠家的產品來源於開源代碼，不過目前已經於開源社區的代碼脫離獨立發展，今後很難把開源社區的一些新技術直接引入自己的數據庫產品了，比如Gaussdb和openGauss已經完全脫離了開源的PG和PGXC，已經只能獨立往前發展了。而另一部分廠家在對自己的數據庫產品做封裝的時候十分謹慎，保持着與開源社區代碼的兼容性，這樣他們可以繼續跟上開源社區的腳步。
數據庫產品的成功絕對不是技術堆疊的成功，而是需要有大量的應用場景磨合才能逐步成功的。如果僅僅依靠自己那幾百個用戶，想要發展出成熟的高水平的商用數據庫產品來，那幾乎是不太能的。依靠開源社區的廣大用戶來研發自己的數據庫產品不失爲一種比較好的策略。
打造國產數據庫開源生態也是一種十分不錯的策略，從今年的鯤鵬開發者大會上可以看到，擁抱openGauss開源社區的企業越來越多。利用華爲巨大的研發投入抱團取暖，把國產的openGauss開源社區做好做大，也是國產數據庫發展的一條不錯的道路。
國產數據庫種類繁多，來源各異，因此把國產數據庫的家譜高清楚也不是一件容易的事情，昨天一個朋友畫了一張信創數據庫的圖，讓我幫忙看看是否正確。從中受到啓發，我畫了一張更全的國產數據庫譜系圖，我會把它附在本文的結尾處。本圖僅僅是我個人的認知，並不權威。因此圖中可能存在一些疏漏，如果大家發現問題，可以留言告訴我。
畫這張譜系圖也並不是爲了證明大多數國產數據庫是開源套殼，剛纔我就說過我十分贊成國產數據庫擁抱開源社區。實際上國產數據庫廠商對是否使用了開源代碼往往遮遮掩掩是很沒必要的。在自己產品中大膽的聲明基於開源代碼也沒啥丟臉的，反而是正確的聲明開源代碼是尊重知識產權的表現。你如果去看看Oracle的版權聲明，會發現，Oracle數據庫的代碼中也使用了大量的開源代碼。
正確的聲明開源代碼，不僅僅是國產數據庫在尊重知識產權方面的表現，也爲用戶能夠能更好的選型數據庫和使用數據庫提供了便利。如果某個用戶以前大量使用過PG數據庫，那麼他們在XC數據庫選擇的時候，選擇一個和PG數據庫有淵源的商用數據庫產品是不是更合適一些呢？如果我是企業的IT主管，我肯定會這麼考慮。
作者|白鱔