上周在卡內(nèi)基梅隆大學(xué)的數(shù)據(jù)庫(kù)研討會(huì)上，SpacetimeDB做了一場(chǎng)分享。會(huì)后我翻他們官網(wǎng)，看到一份與Convex的性能對(duì)比——數(shù)字差得離譜：前者號(hào)稱(chēng)每秒10萬(wàn)筆交易，后者只有100筆。

這份對(duì)比只寫(xiě)了"特定場(chǎng)景"，沒(méi)給任何細(xì)節(jié)。數(shù)據(jù)庫(kù)行業(yè)的營(yíng)銷(xiāo)套路我太熟了，這種模糊表述通常是坑。

Convex很快發(fā)了篇博客回應(yīng)，全程沒(méi)點(diǎn)名，但意思很明確： benchmark 別亂比。SpacetimeDB直接對(duì)號(hào)入座，回了一篇毫不客氣的文章，核心論點(diǎn)就一句——

"這不是蘋(píng)果比橙子。"

他們列了五條技術(shù)差異，想證明差距真實(shí)存在。但仔細(xì)看會(huì)發(fā)現(xiàn)，這些差異恰恰說(shuō)明兩家在做完全不同的事：

第一，架構(gòu)定位。SpacetimeDB把數(shù)據(jù)庫(kù)和應(yīng)用服務(wù)器合二為一，Convex則是傳統(tǒng)的客戶(hù)端-服務(wù)器分離。這決定了它們的優(yōu)化方向完全不同。

第二，事務(wù)模型。SpacetimeDB用存儲(chǔ)過(guò)程在服務(wù)端完成全部計(jì)算，Convex走客戶(hù)端執(zhí)行。前者省了網(wǎng)絡(luò)往返，后者給了開(kāi)發(fā)者更多靈活性。

第三，查詢(xún)方式。SpacetimeDB用Rust寫(xiě)存儲(chǔ)過(guò)程，Convex用TypeScript寫(xiě)查詢(xún)。語(yǔ)言性能差異被算進(jìn)了"數(shù)據(jù)庫(kù)性能"里。

第四，訂閱機(jī)制。SpacetimeDB的訂閱是函數(shù)級(jí)別的，Convex是查詢(xún)級(jí)別的。粒度不同，適用場(chǎng)景也不同。

第五，數(shù)據(jù)模型。SpacetimeDB是關(guān)系型，Convex是文檔型。底層存儲(chǔ)結(jié)構(gòu)決定了某些操作天然更快或更慢。

看完這五條，問(wèn)題很明顯：這確實(shí)不是蘋(píng)果比橙子，是蘋(píng)果比橙子、香蕉、西瓜一起比。SpacetimeDB的10萬(wàn)TPS是在"存儲(chǔ)過(guò)程內(nèi)完成所有計(jì)算"的場(chǎng)景下測(cè)的，Convex的100TPS是"客戶(hù)端發(fā)起復(fù)雜查詢(xún)"的場(chǎng)景。兩個(gè)數(shù)字都真實(shí)，但放在一起就是誤導(dǎo)。

數(shù)據(jù)庫(kù)行業(yè)的 benchmark 亂象不是新鮮事。2010年代的NoSQL大戰(zhàn)里，MongoDB和Cassandra互相指責(zé)對(duì)方"調(diào)優(yōu)到不公平"；NewSQL時(shí)期，CockroachDB和TiDB的對(duì)比也吵過(guò)好幾輪。核心矛盾一直沒(méi)變：廠(chǎng)商想用一個(gè)數(shù)字概括復(fù)雜系統(tǒng)，但真實(shí) workload 千差萬(wàn)別。

SpacetimeDB的文章有個(gè)細(xì)節(jié)很有意思——他們承認(rèn)Convex的測(cè)試"沒(méi)有針對(duì)性能優(yōu)化"，但又說(shuō)"即使優(yōu)化了也追不上"。這種話(huà)術(shù)是典型的"先立靶子再開(kāi)槍"：先假設(shè)對(duì)方不會(huì)優(yōu)化，再證明自己更強(qiáng)。

Convex的回應(yīng)相對(duì)克制，只講自己的設(shè)計(jì)哲學(xué)，沒(méi)接招打口水戰(zhàn)。這種策略在數(shù)據(jù)庫(kù)行業(yè)更常見(jiàn)：技術(shù)人討厭營(yíng)銷(xiāo)話(huà)術(shù)，但尊重工程取舍的誠(chéng)實(shí)討論。

這件事給開(kāi)發(fā)者的啟示很實(shí)際：看到性能對(duì)比數(shù)字，先問(wèn)三個(gè)問(wèn)題——什么硬件配置？什么數(shù)據(jù)規(guī)模？什么查詢(xún)模式？缺了任何一個(gè)，數(shù)字就是噪音。

SpacetimeDB的技術(shù)方向本身有亮點(diǎn)，邊緣計(jì)算場(chǎng)景下"數(shù)據(jù)庫(kù)即服務(wù)器"的架構(gòu)確實(shí)能減少延遲。但營(yíng)銷(xiāo)上踩的坑，恰恰說(shuō)明這個(gè)團(tuán)隊(duì)對(duì)B端市場(chǎng)的溝通還不夠老練。數(shù)據(jù)庫(kù)是賣(mài)信任的產(chǎn)品，一次夸大其詞的對(duì)比，修復(fù)成本遠(yuǎn)高于多做幾個(gè)真實(shí)場(chǎng)景的 benchmark。