The problem with mixing Python and SQL is that there can be an impetus toward something that we might call the All Singing, All Dancing, All SQL solution. The idea here is that the relational database is somehow the ideal platform and Python corrupts this by injecting needless object-oriented features.

The all-SQL, object-free design strategy is sometimes justified as being more appropriate for certain kinds of problems. Specifically, the proponents will point out summarizing large sets of data using the SQL GROUP BY clause as an ideal use for SQL.

This kind of processing is implemented very effectively by Python's defaultdict and Counter. The Python version is often so effective that a small Python program querying lots of rows and accumulating summaries using defaultdict might be faster than a database server performing SQL with GROUP BY.

When in doubt, measure. When confronted with claims that SQL should magically be faster than Python, you should gather evidence. This data gathering is not confined to one-time initial technical spike situations, either. As usage grows and changes, the relative merit of SQL database versus Python will shift too. A home-brewed access layer will tend to be highly specific to a problem domain. This might have the advantage of high performance and relatively transparent mapping from row to object. It might have the disadvantage of being annoying to maintain every time a class changes or the database implementation changes.

A well-established ORM project might involve some initial effort to learn the features of the ORM, but the long-term simplifications are important benefits. Learning the features of an ORM layer can involve both initial work and rework as lessons are learned. The first attempts at a design that has good object features and still fits within the SQL framework will have to be redone as the application trade-offs and considerations become clearer.