ベンチマーク
DBMSの様なミドルウェアは、機能的な差別化が難しいので（これが必要ないという意味ではなく）、非機能要件での勝負になります。その中でも処理スピードが速いとかスループットが大きいというのはわかりやすいので、ベンチマーク結果が良い悪いというのが、マーケティング上非常に重要です。
ところで、実際にベンチマークを行って、いい結果がでたら、すぐそれを公開できるかというとなかなか難しいわけです。
理想的には、全く同じシステムを他社のテクノロジーを使って作って、一方当社の技術で同じものを作って比較する。
これこそが、公正（それでも負けた方は、作り方が悪いだの難癖がでるかもしれませんが、）でかつ確実な方法ですが、このような２重投資は普通あり得ません。（学術的なものであれば、ないともいいきれませんが）
そうすると、非常に単純化されたシナリオでのベンチマークになりがちです。
昨今のハードウェアの進歩により、そのシナリオでは、どの製品もそこそこいい結果がでるので、差別化が難しいです。
とはいえ、現場では工夫や苦労を重ねながら、他社製品よりも良い結果を得ているケースもたくさんあります。
ですが、これらを一般公開することは、ほぼ不可能です。
理由は、大抵の商用RDBMS製品のライセンス条項に、他社製品との比較情報を公表する際には、そのベンダーに事前承諾を得る必要があると書かれているからです。
普通に考えれば、自社製品に不利になる情報を一般公開することを許諾するはずがありません。
そうすると、次にTPCの様な業界標準のベンチマークの結果を公開しろという話になります。
TPCは実際のシステムに近い性能指標を得るということを目標にしていますが、最大公約数的なアプローチですので、現実のアプリケーションシナリオからはまだまだかけ離れているのではないかと思います。
さらにこれを実施（継続的に）していくには、莫大な費用がかかり、これは体力に勝る大手ベンダーに圧倒的に有利です。
さらにTPCベンチマークを実施しているベンダーは、このベンチマークで良い結果を得るためだけに製品を特別にカスタマイズしているという話を聞いたことがあります。（本当かどうかの確証はありません。）
これは、実際の利用者にとって何のメリットもありません。
残念ながら大手ベンダーに比して小振な当社がこの土俵で勝負するのは得策ではありません。
ということで、当社が力を入れて実施しているベンチマークは、実際にいろいろな所で稼働しているアプリケーションのワークロードを分析して、極めて実稼働システムと似通った自動運転できるベンチマークシナリオを開発して、それを様々なプラットフォームで動作させて、スケーラビリティの検証やサイジングの参考にするという方法です。
現在も様々な所で、ベンチマークを実施していますが、以下は2009年に実施されたベンチマークに関するレポートです。
医療情報システムという特定のバーチカルに特化しているシステムのため、ほかの産業用システムに携わっている方々にはピンとこない内容かもしれませんが、このレポートに記載されている結果は、信じられないくらいすごい結果です。