我使用哪個數據庫：PostgreSQL 或 MySQL?這個老生常談的問題已經困惑了開發者至少兩年了。我全面地接觸了這兩個數據庫系統（MYSQL有一年，而Postgres有二年了），而且對MySQL網站提出的關於兩者之間的差異非常好奇。
1999年9月，當我們正開始對SoureForge架設基礎的時候，我對這兩個數據庫作了性能測試。當時，盡管我已經習慣於使用Postgres完成所有工作，但兩者的性能差異是如此之明顯以至與我們不得不采用MySQL。其他的慣用MySQL的開發者也擁護這個決定。 在當時，這個性能測試要勝於平時任何人為的測試。我想看看這兩個數據庫在網站某一具體的網頁上應用的情況。所提及的這個網頁是SourForge討論區。它包括3個表的簡單相關結合。每個表有20-30,000行數據。以及遞歸的實現和嵌套的信息，所以數據庫在此頁上的應用確實是一個瓶頸。
開始實行，我從庫中卸下了真實的數據。編輯了SQL表，並且將其導入MySQL 3.22.30和 PostgreSQL7.0.2，運行在擁有1G RAM 的VA Linux quad-xeon 4100 server上的Red Hat Linux 6.2上。 使我陷入的第一個問題是，在Postgres中，有一個不可思議的問題：每行數據最多只能有 8K。在信息公告板上，你時常會超過每行8K的限制。所以Postgres在導入數據時阻塞。為了能繼續使用，我只得將數據的“body”拋棄，並且重新導入數據。Postgres 開發小組已經意識到了這個限制，並且在7.1的版本中修改了，而且他們告訴你，你可通過重新編譯Postgres使得它支持32K/每行，盡管這樣做會使整個系統的性能受到影響。 在這一點上，我又陷入了Postgres另一個小問題上，它的“serial”數據類型（等價於 MYSQL的auto_increment)會造成一個“sequence”：當它的雙親表被拋棄時，它本身不被拋棄。因此，當你想重新創建這個表時，會引起一個名字沖突。有許多新的用戶被這個問題所困惑，所以這些問題使Postgres在測試中失去一些優勢。相反，MySQL聰明到它可以在你導入數據的時候對 auto_increment進行自動增量，然而Postgres的sequence 不可以在你導入數據時重置，從而引起新插入操作的失敗。
方法
為了盡可能地真實，我從網站上選擇了實際的網頁，並且使它輕巧地交叉於MySQL和 Postgres之間。這基本上意味著所有MySQL_query()調用將被pg_exec()替換。這個頁包括許多選取與連接操作，與典型的網站做的差不多。 一旦這個測試頁運行和調試，我便使用“AB”，就是"apache Benchmarking"應用集，從我的工作站通過我的100M局域網到達quad-xeon服務器。為了在負載的數量上得到一個概念，我使用AB進行各種並發連接的測試，從10-120,當離開了這些頁後，這個數穩定在了 1000上。 為了更加地接近實際應用，我在腳本中安置了一個隨機數生成器，它插入頁面的10%的數據到數據庫中。在PHPBuilder中所有討論區頁面有10%是作為發送新信息的。 進一步地，就以上所說，都使用從現成的數據中提取的數據，你得不出比此更真實的情況了。
數值
實際測試結果：
並發連接 w/p:
10 客戶 - 10.27 頁/秒333.69 kb/s
20 客戶 - 10.24 頁/秒332.86 kb/s
30 客戶 - 10.25 頁/秒333.01 kb/s
40 客戶 - 10.0 頁/秒324.78 kb/s
50 客戶 - 10.0 頁/秒324.84 kb/s
75 客戶 - 9.58 頁/秒311.43 kb/s
90 客戶 - 9.48 頁/秒307.95 kb/s
100 客戶 - 9.23 頁/秒300.00 kb/s
110 客戶 - 9.09 頁/秒295.20 kb/s
120 客戶 - 9.28 頁/秒295.02 kb/s (2.2% 失敗)
並發連接w/10% 插入:
30 客戶 - 9.97 頁/秒324.11 kb/s
40 客戶 - 10.08 頁/秒327.40 kb/s
75 客戶 - 9.51 頁/秒309.13 kb/s
MySQL
並發連接測試 w/p:
30 客戶 - 16.03 頁/秒 521.01 kb/s
40 客戶 - 15.64 頁/秒 507.18 kb/s
50 客戶 - 15.43 頁/秒 497.88 kb/s
75 客戶 - 14.70 頁/秒 468.64 kb/s
90 - mysql 崩潰
110 - mysql 崩潰
120 - MySQL 崩潰
並發連接測試w/op:
10 客戶 - 16.55 頁/秒537.63 kb/s
20 客戶 -
