ORMs (especially the Django ORM) fulfill 95% of my needs. For the 5%, I use raw SQL via the ORM's escape hatch (which Django and SQLAlchemy provides). To be fa

ORMs (especially the Django ORM) fulfill 95% of my needs. For the 5%, I use raw SQL via the ORM's escape hatch (which Django and SQLAlchemy provides). To be fair, my needs aren't that complex, I do mostly CRUD on database tables, most of the business logic is handled in my code, eventually wrapped in a `@transaction.atomic` (thank you Django). If I need stored procedures, I'll add a Django migration which creates the said procedure with raw SQL. If I need to manage the schema myself, I'll also make a Django migration with raw SQL, then I'll create Django unmanaged models. For the portability across RDBMS, it's nice to have an SQLite database in the dev environment, so that the developer does not need to run a PostgreSQL instance (in docker or whatever). And for the test suite, I even use an in-memory SQLite database. I do put my ORM queries in a specific module which provides a higher level API, I will have functions like `get_users_sent_invites` or `publish_article` etc... so that the rest of my code never sees database code. A function `get_user_by_id` will return the User model or None, and handle the ORM's potential exceptions to return meaningful errors to the business logic. It also makes database access easier to test and benchmark. You might call this DAO or not, terms are irrelevant, it's just good practice to separate concerns IMHO.