In contrast to my recent rant about database comparisons, I was pretty impressed with the Oracle 10g vs PostgreSQL 8 vs MySQL 5 article. The two articles don’t compare the same issues, but I’d like to point out how well this one done.
Right from the start the author states his bias upfront (he is a long time Oracle admin), along with what was being compared. In this case the focus was on installing on a lower end Windows 2000 system. All of the factors were spelled out and the scoring method was described in sufficient detail. Each factor had some discussion and and a score for each database.
Overall I’d consider this a good example of a database comparison, it has a well defined (and narrow) focus with an upfront scoring system. My only complaint with this review was in the “Documentation and Getting Started Support” section. Although PostgreSQL and MySQL basically have the same issues in the discussion area, the scores are different. Given how well the rest of the review was done I don’t think this issue completely ruins the review, just provides a low point.
I hope that the author, Lewis R Cunningham, continues to do additional reviews of these three databases using this same format.
10 replies on “Oracle 10g vs PostgreSQL 8 vs MySQL 5”
I have already red tha benchmark and felt good as it praises Pgsql, although the test is too basic, but it have taken with both hands what the most important aspects of each daatabase.
I believe that any DataLayer must be a simple code block, that they allow operations against DB.
That code block would not have to know on the Business Entities. Single to specialize it is to execute the operations (Store Procedures and SQL Sentences) against the engine DB (SQL, Oracle, DB2, etc.), with which this setting.
Finally, I invite to you to download the DataLayer.Primitives Public Version.
This is very cool Data Layer š
DataLayer.Primitives – Readme!
http://forums.microsoft.com/msdn/ShowPost.aspx?PostID=1389
Cheers,
Javier Luna
http://guydotnetxmlwebservices.blogspot.com/
Joesph,
Thanks for reviewing my article. I enjoyed writing it and plan to work more with PostgreSQL in my freetime. I’m not a convert yet but time will tell. š
Just a note on why I ranked them the way I did on documentation. I think I mention it somewhere in the article that the version of MySQL was a beta and that I was giving them a little “benefit” because of that. PostgreSQL 8.0 was production and like you said, the lack of documentation was about the same. It was a judgement call on my part and I know not everyone agrees but it was an honest call on my part.
I ran a poll on my suite101 site asking which databases I should cover. I listed Oracle, MYSQL, PostgreSQL, Firebird and xBase. I didn’t get many responses at all and none for postgreSQL, but I will be writing a comparison of utilities available out of the box in an upcoming article. Again, I’ll compare Oracle, MYSQL and PostgreSQL.
Again, this will be on low end hardware (although a little higher end than the last one, PIII 1GHz with 512MB) and more for a user or business type rather than a programmer type.
The emails I’ve gotten have mostly been asking me to cover more advanced Oracle topics.
Thanks again for the good words,
Lewis R Cunningham
http://www.suite101.com/welcome.cfm/oracle
http://blogs.ittoolbox.com/oracle/guide/
Hi,
Lewis Cunningham again. Just wanted you to know I published an opinion piece on the open source competition that Oracle faces from MySQL and PostgreSQL.
I also talk a little about Netezza which uses PostgreSQL.
It’s on my ITToolbox blog, http://blogs.ittoolbox.com/oracle/guide/archives/004312.asp
Actually in the last week or so I wrote a couple of blogs about Oracle and open source. Some people believe Oracle can go open source. I don’t think so.
Anyway, just wanted to let you know. If you think anyone else would be interested, please let them know also.
Thanks,
Lewis C
http://blogs.ittoolbox.com/oracle/guide/
http://www.suite101.com/welcome.cfm/oracle
one point that i missed in all of this is performance and scalablity….where postgres hits dead last for this postgres user. I say this because postgres is limited in it ablity to make use of multiple CPUs, trigger based replication clustering, and chinese arithmatic required to make use of RAM and hardware.
Lewis-
Thanks for the heads up. I liked the first article because you picked a very specific part of the software and explained what you were looking for and how you were going to score it. This second article isn’t as precise in the this same way. I think your conclusion is correct, but I’d like to see less of the general discussion and more of the specifics because I think that helps people understand the issues in greater detail.
Teo-
I’m not sure what why you indicate that PostgreSQL has limitations with multiple CPUs. Each job forks another process that can be run on a different CPU. That is really a job for the OS though, not the database software. I believe that at least one of the replication solutions involved triggers, so again I’m not sure why you indicate that as limitation/issue. I’m not familiar with the needs of Chinese arithmetic so I can’t speak as to how well that is or isn’t supported. Getting the hardware to scale is mostly a job of the OS.
Joseph: “Iām not sure what why you indicate that PostgreSQL has limitations with multiple CPUs. Each job forks another process that can be run on a different CPU. That is really a job for the OS though, not the database software”.
The issue was one with the time that certain locks within the database were held for certain specific operations. If you have a large SMP machine (dozens of CPUs) see some checkins to the 8.1 branch from Tom L and read the discussions on the mailinglist to see if these apply to you.
Note that postgresql already uses less locking – especially less exclusive locking – than other databases; so while it’s true this is a “limitation with multiple CPUs” when compared about theoretical limits postgresql is already ahead compared to other databases,
Here is a direct link to the discussion, along with benchmark results.
http://archives.postgresql.org/pgsql-general/2005-03/msg00837.php
On a 16 CPU Altix with 192GB of memory, the previous release 8.0.X wouls start decresing in performance with 32 or 64 clients making simultaneous requests. With the improved SMP support (2005-03-16 and later) we no longer see the performance falloff and with 32 simultanous clients the new version is about twice as fast as 8.0.X
On small SMP systems (a quad-CPU Itanium and a quad-CPU AMD64 were also benchmarked) the changes were less dramatic.
Ahhh, it wasn’t clear to me that from teo’s comment that what he was referring to locking issues with multiple CPUs. Thanks for clearing that up.
Yeah, I get the feeling teo just heard a rummor about the patch and exaggerated it to the point of creating some fud — there really aren’t that many 16+CPU systems out there today — and even if they were, the patch has been posted and anyone with such a system can afford the resources to maintain that patch themselves until it’s in the mainstream release.
I am curious what he meant by chinese math being different too.
I just though I’d answer constructively though š