InnoDB is a high-reliability and high-performance storage engine for MySQL. Starting with MySQL 5.5, it is the default MySQL storage engine. Key advantages of InnoDB include:
Its design follows the ACID model, with transactions featuring commit, rollback, and crash-recovery capabilities to protect user data.
If I have a varchar(2) and I insert 3 characters in that field - I should expect that to error, not warning and silently truncate (which isn't picked up if you are doing inserts on the application level). I know there are options to turn it into an error - but, that is not the default.
Also, if i screw up a create table, inside a transaction .. i expect that create table to roll back too.
Both things which postgres does perfectly. Not to mention, plpgsql is way easier to write with less stress than whatever horrible extensions to SQL that MySQL has for procs and triggers.
So, if I'm reading this right, a release of MySQL that came out only a year ago and is still of development quality finally has ACID compliance by default? Or has there been a production-grade release since then?
EDIT: My mistake. Apparently I'm not sufficiently familiar with MySQL's revision number practices. According to this: http://dev.mysql.com/doc/refman/5.5/en/news-5-5-x.html#news-... 5.5.x is a production release; I saw an odd minor version and assumed it was dev, since that's what I'm used to everywhere else. My other questions still stand, though.
That's not really the point though - the different engines provided are for different tasks.
MyISAM for example supports fulltext indexes by default which was/is probably one of the most useful features for web development which explains why MySQL is so popular in that arena.
Whatever default was selected by MySQL is irrelevant - do your research and pick the right tool for the job.
"the different engines provided are for different tasks"
You should think of them more like separate DBMSs that are tied together in one system. The semantics change depending on the storage engine, so they aren't just drop-in replacements.
"MyISAM for example supports fulltext indexes..."
PostgreSQL has supported full text search for a long time.
I didn't claim they are drop in replacements, just like I wouldn't claim you can just jump from MySQL to PostgreSQL.
What I said was you need to do your research and pick the right tool for the job.
I haven't used PostgreSQL for quite a few years but I think it got built-in support for fulltext indexes in v8.3 (April 2008) whereas MySQL had them in v3.23 (April 2001).
A lot of shared hosting providers/package management systems wouldn't have supported/installed the extra extensions to make PostgreSQL support fulltext indexing prior to it being built-in I suspect.
To be clear, I don't care what you or anyone else uses - I was simply pointing out that just because it was the default engine it didn't mean you had to use it!
For what it's worth, AFAIK there is no reason other than development effort, for InnoDB not to have full text search. I am sure it will get it eventually.
MySQL had InnoDB at least in the 4.x branch. 5.5 just made it the default storage engine for when you don't specify an engine type. All sensible developers have been using InnoDB for a long time. Others suffered (I am looking at you, WordPress).
Its design follows the ACID model, with transactions featuring commit, rollback, and crash-recovery capabilities to protect user data.
http://dev.mysql.com/doc/refman/5.5/en/innodb-storage-engine...
Edit: swapped out Wikipedia for MySQL's official docs.