Magento

InnoDB is not an exotic option. MyISAM is the exotic option. MyISAM is meant to be used for log tables. Any serious data should be in InnoDB. EVERY site that accepts money should be in InnoDB. This is why many other databases (PostgreSql, Oracle) all default to table types just like InnoDB.

The real reason why your host does not want to enable InnoDB is because then your DB would not count against your disk usage, so it makes it very hard for him to charge you more if you have a large DB.

I think that depends on your work environment. As a designer, among CMS, e-commerce platforms and other PHP applications, I never had to choose anything beyond MyISAM and I thought that was a standard.

My host has already activated InnoDB so I am not complaning for my situation as it is solved I just say, and I repeat, this is another barrier for magento’s healthy spread. But we’ll get over it, I am sure of that.

I have to agree with the last poster. I have just been contacted by a client currently hosted on Hostgator whom is experiencing some issues with his cart. He wants to move over to Bluehost or move over to my dedicated server. However, after reading these posts, I am not so sure that installing innoDB on my dedicated server is such a good idea as I have plenty of Web Sites hosted there that could not suffer a slowdown in performance.

In addition, I am not so sure that my client’s issues are related to the lack of innoDB on the server. I am still investigating that issue but I am starting to think that’s not the problem.

In any event, I think it is short sighted of Magento to require innoDB considering that support among the run of the mill shared hosting providers is at best sketchy.

As someone who is researching Magento and compatible hosts, I derived the most value from m00dawg’s post. My overview interpretation is that Magento’s designers prioritized smart architecture over speeding up Magento adoption. Kudos then to the Magento team.

Chris

I know this is a bit of a bump, but I fancy adding my own two cents.

InnoDB comes enabled as standard with MySQL.  For it not to be there involves the host specifically disabling it (skip-innodb in the my.cnf file)

There is no major skills adjustment necessary for coping with InnoDB over MyISAM unless you’re getting to the level of doing nitty gritty performance tweaks. For the most part InnoDB will perform well out-of-the-box.

InnoDB has huge advantages over myisam, and you’ll find pretty much most major databases and software will use it.  Refusal to support it would indicate a hosting company you maybe ought to be thinking twice about.

Some of the advantages of innodb:

Transactional - every transaction is logged.  In the event of a crash the chances of having corrupted data in the database is much, much lower.  The database runs over the transaction log contents to try to be sure everything got in safely and correctly.  InnoDB is nigh on bullet proof, and MyISAM is far, far from it.  It really doesn’t take all that much to corrupt a MyISAM database.  Shockingly little in fact.
Personally even with low load stuff I wan the peace of mind InnoDB provides in regards to data safety.

Row Level Locking - When MySQL writes to a table, be it updating, adding or deleting rows, or whatever, it has to lock things first to ensure nothing else can write data. Given MySQL will execute queries in parallel that’s critical.  MyISAM only offers table level locking.  So if you’ve got two queries that come in that update completely different rows the second one has to wait for the first one to finish before it can do it’s work.  InnoDB supports row level locking.  In that scenario both queries could be executed simultaneously because only the row was locked for editing rather than the entire table.
Under any kind of transaction load row level locking will provide a significant performance and data consistency boost.

Backups.. well if you’re stingy enough to fret about the cost of innodb over myisam, I’m going to guess you’re “once a day” backing up types.  In which case try adding this to a cron job about an hour before your file backup is due to take place:
mysqldump --opt -u <username> -p <password> magento-db-name > magento.sql
That’ll leave you a nice flat file you can re-import into MySQL easily:
mysql -u <username> -p <password> < magento.sql