After 30 months with ORMs, one engineer's verdict: just learn SQL

A developer reflects on two and a half years of working with SQLAlchemy and Hibernate against Postgres and SQLite, concluding that object-relational mappers are useful for augmenting SQL but should never replace it. The core problem is the object/relational impedance mismatch, which shows up concretely as entity-identity headaches, dual schemas, awkward data retrieval, and the partial-object problem. He adds his own complaint: ‘attribute creep,’ where wide tables accumulate columns until querying by entity effectively becomes a SELECT * that drags hundreds of fields—and cascading foreign keys—into every fetch. In one case a single object required 14 joins across a 600-attribute table, and rewriting a projection by hand cut query time from minutes to seconds.

The recurring theme is that using an ORM well still demands fluency in SQL, especially for anything involving joins, window functions, or performance tuning—at which point the abstraction mostly adds obfuscation. His preferred approach is to describe tables through the ORM for convenience but write actual queries with SQL templating, treating queries as the API to the database and thinking in terms of functions and return types rather than objects. He also flags dual-schema redundancy and, worse, migrations: ORMs offer little help managing schema change in a persistent database.

Entity identities and transactions round out the critique. Identifiers mean a memory pointer in the application but persisted state in the database, forcing manual cache flushes or partial commits to obtain real IDs. Transactions, being dynamically scoped, clash with the lexical scoping of most languages, producing boilerplate, passed-around session objects, and functions that only work in certain contexts. He closes by reconsidering stored procedures—long treated as heresy—suggesting the rise of devops may narrow the old divide between developer and database.