I've increasingly formed the opinion over the past few years that (almost) anyone writing software, certainly in the SME or 90% of open-source space, simply shouldn't be writing raw SQL.
This is the 21st century, and all the major programming languages have these things called ORMs. Since all you actually wanted from your database was some kind of load/save/search for the objects that make up your software's state, it turns out encoding that metaphor at the object level is much nicer than writing the code to do it all yourself.
The added bonus of this is that when you want support for a new DBMS, you just need to see if your ORM has support. Generate a schema, run through all your tests, a couple of minor fixes, job done. And you'll make your sysadmin a happy man by not dictating a choice of DBMS to him or her which makes their life harder.
You may be drawing breath to argue that writing the raw SQL yourself by hand is 'more efficient', but come on. Your blog has a couple of hundred posts and maybe a few thousand comments. The daily hit rate of ten and a half people isn't going to tax even MySQL - so whether you use it, PostgreSQL, or even the free edition of IBM's DB2 (eight-character limit on database names, anyone?) really doesn't matter. It's an implementation detail you shouldn't worry too much about, and certainly shouldn't prematurely optimize by getting too familiar with.
Django has led the way in the Python world for years on the ORM question, but all the other languages have them too. Make the jump, and you can always escape to raw SQL if you really need it in one corner of your application.