The author concluded that ORMs provide limited benefit and should supplement rather than replace SQL.

He has worked for 30 months with PostgreSQL and SQLite, using SQLAlchemy and Hibernate, and has handled event‑based timelines and reporting tasks.

He describes several challenges: tables can accumulate many columns, leading to wide tables that are difficult to query efficiently when using the ORM; queries that rely on the ORM’s query API can generate excessive joins and cause performance problems; foreign keys often require many joins to retrieve a single object; managing entity identities between the application and the database adds complexity; transaction handling requires dynamic scoping and careful boundary placement; and schema changes are cumbersome because the database remains the source of truth while the application must be updated separately.

He notes that ORMs still require knowledge of SQL to write efficient queries, and that many developers spend more time translating database rows into objects than optimizing the queries themselves.

The author recommends treating the database as a data type with a query API, writing queries directly or using templated SQL rather than relying on the ORM for query generation, and learning SQL directly to avoid the “ORM makes it easy” trap.

He adds that his experience reflects his specific use case and does not prescribe a universal approach.