MySQL IS a database (Score 2)

So what if it doesn't support transactions? It is faster because it doesn't. IMHO, a good programmer should be able to program with or without transactions. In most cases where one needs transactions, it isn't too difficult to write the code around it, and often have it work better than transaction based code (especially with MyISAM table, which don't have the transaction capability slowing them down).

Again IMHO, transactions are a crutch. At times, they are a useful crutch, but a crutch nonetheless. There is an excellent chapter (appendix?) in the MySQL manual discussing the absence of transactions and some of the workarounds.

Row locking is a whole 'nother issue. While you can implement row-locking with atomic SQL statements, it is more efficient for the DBM to do this. Besides, locks need to go away when the connection goes away, which manual locks do not. MySQL could fix this by allowing a connection to provide a query or queries that the server should always execute when the connection is closed, so that if something disrupts the connection, manual locks can be removed...