Keep in mind that I'm not an ActiveRecord fan; the internal architecture drives me nuts, but I do like that I can use SQL when I want to, without ActiveRecord g

Keep in mind that I'm not an ActiveRecord fan; the internal architecture drives me nuts, but I do like that I can use SQL when I want to, without ActiveRecord getting in the way. Here's the first Google hit I came across when looking to use PostgreSQL fulltext searches under Hibernate: https://forum.hibernate.org/viewtopic.php?p=2447426 https://forum.hibernate.org/viewtopic.php?p=2447426 That's 50+ lines of code, plus some XML configuration, spread over four files, to perform a highly database-specific task that could have been better handled in raw SQL in a single line of code. Also if I remember correctly, Hibernate, like DataMapper, requires that you specify your field types in the code, which makes migrations (updates to the DDL) a royal pain in the ass, and migrations are an important task in the operational lifecycle of an application. I'm a big believer in having sole sources of truth, and so I treat the database as the only source for information about the structure of the database -- I don't want to have to specify that information in two places, where it can get out of sync. Now, it's been years since I touched Hibernate, and it's probably gotten better. But from what I can tell, the above issues are design decisions; part of a conscious effort to hide the internals of the database from the developer, no matter the cost. This is why people claim that ORM is an antipattern. Because, while an ORM solves 90% of your problems, for that remaining 10%, nothing beats being able to talk directly to the backend.