On Wed, Jul 8, 2009 at 10:05 PM, Greg Smith<gsmith@xxxxxxxxxxxxx> wrote: > On Wed, 8 Jul 2009, Ivan Sergio Borgonovo wrote: > >> You can actually build up closed source software with MySQL as a >> server, it depends on how you do it. > > I seriously doubt that: http://www.mysql.com/about/legal/licensing/oem/ > > The terms under which you can treat MySQL as a more open piece of software > are pretty tightly constrained: > http://www.mysql.com/about/legal/licensing/foss-exception/ Back in the day (v6.5.2) I picked pgsql because it had the features I needed, good enough performance, fair stability (as good or better than mysql's of the day) and that it didn't have mysql's restrictive licensing. Over time I think pgsql has come much further than mysql, and the focus there has never been as clear as it is here, in terms of "don't surprise the user in dangerous ways." I think the mysql fanbois who say these things in logs are usually just not at all familiar with using pgsql on a daily basis. Under any modern load, pgsql and mysql are usually no more than +/- 30% or so in performance, unless you're using a broken GA release like 5.0.x or so (whichever one tweakers tested them on that it imploded on the Sun 32 thread CPU). To be fair, pgsql has had performance regressions show up, and some of them take a few weeks to figure out. But they're usually not as catastrophic as the one that mysql had in that test. So when I have to use MySQL it's a small project / application that doesn't tax the machine or the db. Like internal ticketing maybe. Whenever I think "man, this might get really big or have thousands of hits per minute." I want pgsql. When I need to process and replicate 200 transactions per second or more, I really want to use pgsql more than mysql. I know that between log shipping and slony I can guarantee downtimes in the minutes during which things switch over, or are switched by hand, than the possible hours involved should I have to restore from backup. Mysql has come a long way, but the still somewhat loose adherence to data integrity princples makes it a bad choice for important data. Until there's a version that just runs on innodb and only innodb or something like it, which has ALL the cool features (network db, transactional db, full text indexing db) in one handler I don't want to mess with it's sort of fits here, sort of fits there feature set. I am happy about the companies that may be forking it. It'd be nice to have a pure GPL no commercial license version that runs on one solid reliable table handler. Or even allows me, the db to easily pick which ones go where, so I don't have banking systems getting built on myisam. I think that focusing on one good table handler in postgresql has been a winning proposition so far. That and release discipline which has been pretty meh grade in the last few years for mysql. -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
