One key point I made is that I'm no longer convinced that OR mapping layers add much value to a language like Python. Fowler's book Patterns of Enterprise Application Architecture is a good source for some examples of more data-centric approaches to this problem. I did do some work on a Python ORML but never finished it after getting dragged off onto another project. There's a working prototype of the top end (a database row cache and __getattr__()/__setattr__() based object-row mapping), but the database layer isn't done beyond some initial fiddling. I should find some time and finish it.
The resulting effort was surprisingly hard to write. It looks simple until you try explaining how it works to someone else. ORML's aren't easy things to do if you want to take care of complex relationships. Now I'm not convinced that they add much value to Python as Python has fairly powerful native data manipulation capabilities to begin with.
To take the 'simple infrastructure' argument a layer further - if you have an RDBMS for a schema with (say) 5-10 tables it might be overkill, adding a relatively complex piece of infrastructure for little gain. Consider using ZODB, metakit or another lightweight storage engine. As an earlier poster said, they aren't so scalable, but for simple applications they add much less baggage than a client-server DBMS.