>>The answer depends.
>Here is a posting of a speed test.
>http://www.mysql.com/information/benchmarks.html
>
>This was done by Mysql, So.. I hope its not too slighted.
>Bob Lee

http://www.phpbuilder.com/columns/tim20001112.php3
"With that in mind, I decided to test out a full port of SourceForge.net to Postgres. The site was written with a database abstraction layer and it turned out to be a cinch to get it up and running on Postgres, including a full import of all production data from MySQL.

Not only did the site come up on the first attempt, but it ran fine! In fact, our very first benchmarks showed Postgres running 6x faster than MySQL on a very database-intensive page (the "My Personal Page" for logged-in users).

To make things interesting, we ran the exact same code base on MySQL 3.23.26beta and Postgres 7.1 (CVS pre-beta version). The SQL structures were identical, except that I had added Foreign Key constraints to the database schema on Postgres (MySQL doesn't really support foreign keys). This should have tilted the performance in favor of MySQL, because MySQL doesn't do any data validation on inserts/updates, but Postgres did in this test.

...

With 30 clients pounding the test machine, Postgres chugged along at 3.76 pages per second. That sounded really bad at first, until we ran the same test on MySQL. MySQL did so poorly that we eventually cancelled the test and reduced the concurrency to just 5 users, and it still only fared .77 pages per second.

To be clear, this is an unusually intense page and requires 16 queries and joins a dozen tables together in interesting ways. If you're wise, you won't make your entire web application this complex.

To spice up this test, we created a second PHP page that did inserts, updates, deletes, and used transactions. We had 30 clients hit this new page, and 30 clients hit the "My Personal Page" simultaneously. Since Postgres supports transactions, we decided to have 25% of the transactions "rollback" to see if that causes any performance problems.

To be fair, this is a test where we fully expected MySQL would fail - because of its table-level locking. The "My Personal Page" joins several times against our "Groups" table, which was being updated frequently in this test. While it was being updated, of course MySQL would have to wait to get a table-level lock, while PostgreSQL would simply move along using its "better than row level" locking.

Postgres chugged along at 2.05 pages/second, and MySQL simply failed the test and locked itself up (again table-level locking is the major pitfall of using MySQL). MySQL didn't crash, but our benchmarking software (Apache's "ab" utility) timed out when it didn't get any result from MySQL.

The numbers here are telling. MySQL was very slow even at 5 concurrent users, and failed at 15 concurrent users (the graph actually flatters MySQL's performance here).
What Does It Mean?
Well, it means you can't simply cross PostgreSQL off your list because it's a dog anymore. Now, not only does Postgres have dozens of very advanced features that MySQL lacks, but it doesn't appear to be weighed down by those features as it was in the past. And that's good for everyone.

Expect to read more about Postgres here in the future - most notably I'm going to write up a more-detailed article on how to properly use transactions and foreign key constraints in your database. Both features are going to be used throughout the SourceForge code base in the near future. " --Tim

MySQL 4.0 has a way to go before it can catch up to PostgreSQL 7.1 IMO.

JLK
"