- Define a 32-bit field in MySQL. Insert a 64-bit number instead. Common
sense tells you the value would be rejected. Yet MySQL happily folds it
in and carries on its merry way.

- Triggers: PostgreSQL yes, MySQL no. Translates into more work for your
MySQL developers in both creating your app and moving it forward with
each rev.

- Transactions: We've been here before. Suffice to say, MySQL+InnoDB is
almost there. Plain ol' MySQL doesn't have it, which tells you something
about their philosophy towards database design.

- Speed: mHz for mHz, MySQL has PostgreSQL beat for simple searches.
Once you start getting complex, PostgreSQL is competitive. I think this
speed issue is overrated: over time, PostgreSQL has sped up and MySQL
has slowed down which is pretty impressive, considering both have added
features from their early versions.

- Scalability: MySQL dies before PostgreSQL does. PostgreSQL under
extreme load may slow down, but it'll finish. MySQL simply gives up.

If the project is for slapping dynamic html on a page with data not
crucial for business, MySQL is probably fine. But if we're talking
business processes, data you care dearly about, MySQL is out. Lack of
constraints is the deal-breaker for me.

PostgreSQL is more comparable to Oracle. MySQL is more like Access --
quick and dirty.

But boy, they sure are good at marketing. Probably because MySQL is
developed by a single company with venture cap and a public relations
company whereas PostgreSQL is developed out in the open by a close-knit
community.

--
Best,
Al Hulaton    |  Sr. Account Engineer  |  Command Prompt, Inc.
503.222.2783  |  ahula...@commandprompt.com
Home of Mammoth PostgreSQL and 'Practical PostgreSQL'
Managed PostgreSQL, Linux services and consulting
Read and Search O'Reilly's 'Practical PostgreSQL' at
http://www.commandprompt.com

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

               http://archives.postgresql.org