I was so excited to see this InformationWeek.com article reporting that PostgresSQL has proven itself nearly as good as Oracle. On a day billed as “a good day for Open Source”, Sun published a SPECjAppServer2004 result using the Sun Niagra platform running PostgreSQL backing 3 Application Servers running Sun Java Systems Application Server 9.0.
The Sun result was 778.14 JOPS which, as the InformationWeek.com article suggests is roughly 12% under this 874 JOPS Itanium Oracle result. That’s all fine and dandy, but why hand pick that Oracle result over this 1111.96 JOPS Xeon “Cloverdale” Oracle result? I’ll tell you why, it’s because InformationWeek.com was only reporting on this blog entry by Josh Berkus. Josh is the PostgreSQL Lead by the way and Josh knows full well that the 12% in his hand-picked comparison looked a lot better than then 42% thumping Oracle dealt PostgeSQL using 2 little Xeon “Cloverdale” processors. But that isn’t what I’m blogging about.
PostgreSQL: The Worlds Best Application Server
I’m not blogging about the fact that these guys cherry picked results in an attempt to put PostgreSQL on par with Oracle. Afterall, I too dream of the day that everything in the world is free. In the meantime you get what you pay for.
What get’s my ire up about this news piece is the fact that there is no news there. Folks, SPECjAppServer2004 is not a database benchmark. The SPECjAppServer2004 web page puts it like this:
SPECjAppServer2004 (Java Application Server) is a multi-tier benchmark for measuring the performance of Java 2 Enterprise Edition (J2EE) technology-based application servers. SPECjAppServer2004 is an end-to-end application which exercises all major J2EE technologies implemented by compliant application servers as follows:
- The web container, including servlets and JSPs
- The EJB container
- EJB2.0 Container Managed Persistence
- JMS and Message Driven Beans
- Transaction management
- Database connectivity
Yes, there is a database downwind. No this is not a database workload it is an Application Server benchmark. So to say that PostgreSQL made a “good day for Open Source” based upon this result is a lark. But that is not what I’m blogging about.
Cost Metric
SPECjAppServer2004 has no cost metric. By that I mean that there is no cost metric. In fact, the specification lacks a cost metric. Moreover, no published results include cost information. What I’m trying to say is that the benchmark has no cost component. If I started an Open Source project called JOPS Cost Metric Calculator (JCMC), I’d have nothing to work with—but I might get a lot of help I suppose. In fact, if I spent the rest of my life studying the SPECjAppServer2004 specification I wouldn’t find anything about a cost metric. I once saw a Klingon riding a three-legged pink elephant wearing a tee shirt that read, “The SPECjAppServer2004 ghajtaH ghobe’ Cost Metric” which—loosely translated—collaborates with my assertion that there is no cost metric in the SPECjAppServer2004. That’s why I’m a little dissapointed to see Tom Daley’s blog entry with a cost analysis of these SPECjAppServer2004 results.
Summary
Oracle Database has licensed options. Customers can use the best options at prices that fit their budget to solve their problems. Incidentally, Oracle has that choice as well. So when Oracle is competing in an Application Server benchmark, they can use whatever downwind database options they so choose—after all, I heard a rumor that there is no cost component in the SPECjAppServer2004 specification.
Oracle used Enterprise Edition and partitioning. I bet if they tried they could get the same result with Standard Edition or since there are only 8 cores involved, Standard Edition 1. But why bother, THERE IS NO COST COMPONENT. And PostgreSQL comes nowhere close to what Oracle can do with this workload.
What Did He Say?
That’s right, in spite of the blogospherian hopes that PostgreSQL is a 12% heel-biter to Oracle, the full list of audited SPECjAppServer2004 results tells the real story. Not only did Oracle slam this “PostgreSQL result” with the same number of cores—when we consider the 42% thumping Oracle on Xeon 5355 delivered—but Oracle scales as well as this 7629.45 JOPS result with 64 cores will attest. Oh and I forgot to point out that the 778.14 Sun result with PostgreSQL downwind used three application servers. Isn’t it interesting how a single Xeon 5355-based application server was able to push 42% more throughput when using Oracle’s application server with n Oracle database back-end. That is, the Sun result required 3 application servers for a total of 12 cores whereas the Oracle 1111.96 JOPS result used a single Xeon 5355-based application server with 8 cores. Remember, this is an application server benchmark so Oracle pulls 138 JOPS per application server core. That’s a far cry better than Sun’s 65 JOPS per application server core!
When it comes to the database component, I want to see the PostgreSQL 64-core number. Hey, it’s just a porting effort after all. There must be untold countless Open Source contributers working on optimizing the PostgreSQL port to HP-UX for the Superdome.
Where’s Waldo?
There are no SPECjAppServer2004 results for SQL Server in this list. That could very well be the real story.
Kevin Closson's Blog: Platforms, Databases and Storage 
Why would anybody in the world wan’t to have a PostgreSQL server with 64 cores? Using PostgreSQL you don’t have to pay per server/cpu/core (not sure how it works with Oracle nowadays). If the database is designed for the cluster since beginning it performs way better than on a single server with a huge disk array. Oracle is THE software that causes people to buy 64-cored servers in the first place because of it’s pricing policies.
Well the question is wether its “worth” to spend millions of dollars for oracle. It all depends.
Our company migrated from Oracle to PostgreSQL two years ago and using the same hardware we don’t face any performance or reliability problems – saving a *lot* of money.