see this slashdot thread and this report. Here's a great comparison of the 2.

Thoughts:

• John could run MySQL on Windows too
• "[Mysql] might require changing the database type from MyISAM to InnoDB for UPDATE intense applications."
• "MySQL does very good job even on the busiest sites; it certainly has some problems handling hundreds of connections per second, but these problems are resolvable"
• "Postgres does very good job supporting referential integrity, has transactions and rollbacks, foreign keys ON DELETE CASCADE and ON UPDATE CASCADE. MySQL has some basic provisions for referential integrity and transactions/rollbacks. CHECK clause is allowed for compatibility only and has no effect on database operation.

InnoDB tables have FOREIGN KEYs for relational or multi-table delete, and support transaction processing. In MySAM tables FOREIGN KEY is for compatibility only and has no effect on database operation."

• see somewhere here for a handy function for viewing IP addresses
• Digest this comment on large text fields: "To choose between the two databases, you need to understand whether you need the transaction support of Postgres or the large-text-area support in MySQL.", HUH? Postgresql text can support up over 1G of text per field. Also the article says that BLOBS are "special" in PG and MySQL they are "are just fields in the table", again in accurate at best. PG does have the concept of BLOBS and they are special, but this is really just legacy, most people use bytea which is a binary data type that "are just fields in the table" like in MySQL, this isn't new, it's been around a long time."
• read this for Postgres tuning stuff
• "The MySQL scaling problems you're describing are due to using MyISAM tables for an OLTP application. Don't do that. They're fine for read-mostly applications, but the locking is not efficient enough for more. Use InnoDB tables for OLTP apps. The InnoDB tables use an multi-version concurrency control approach just like Postgres does."

-- MattWalsh - 18 Dec 2006