Hibernate/JPA confuses "legacy" with "high throughput", "scalable", and "complex"

I like Hibernate/JPA for dead-simple inserts and update. I detest it for queries. I also detest how the Hibernate documentation totally misuses the term "legacy". When I hear the term "legacy", I think "old and dumb". But on planet Hibernate, "legacy" means "Any application which operates on a piddly amount of data and doesn't buy into our myopic, java-centric view of the cosmos in which a relational database is just a pain-in-the-ass file system whose performance and data integrity issues exist only to perpetuate the hiring of very expensive DBAs".

For example, Hibernate says it doesn't support trigger-driven sequence creation because that's a "legacy" kind of a thing. What if my database is accessed both by Scala, Ruby, Perl, and Java? I'd like to encode some core business rules directly in the database so I don't have to duplicate logic in different languages. I don't call that "legacy". I call it "reality".

Hibernate thinks that compound unique keys are indicative of a "legacy" database. There are perfectly good reasons--from a (gasp!) data modeling perspective--to use complex unique keys and dispense with primary keys. Having to introduce new artificial primary keys into all my tables to make life easier for the object layer is something I am now more or less required to do so as not to infuriate application developers. But there is a real cost to the data model: the data model is forced to violate DRY. The data model has to maintain two redundant definitions of uniqueness: one that is natural and one that is imposed by Hibernate. Hibernate claims that having a foreign key refer to a unique key of the associated table rather than the primary key is "complicated and confusing". This is bullshit.

Hibernate thinks that only "legacy" tables have lots of columns. In reality, it's often very useful to make really fat tables to accomodate what would otherwise be complex, possibly inefficient multi-table queries. I've made fat tables before and I'll make them again. It's not legacy, it's reality.

Hibernate thinks that everyone should have "fewer tables than classes", and then claims that storing some attributes in a secondary table (hello @Secondary annotation) is really only for...you guessed it..."legacy" databases. Hold the phone. What if I have some bit of data that is part of an object but needs database-level security? For example, if I have a patient table and I want to expose access to social security numbers, perhaps I'd like to put the social security numbers in a separate table, or in a separate schema, and have the database manage the security of this table slightly differently? What if I have some huge freakin' columns that map to a particular subclass of an object, but I'd like to keep them stored separately for query performance? What if these columns are extremely rarely used? I don't want to risk pulling them all into memory (which I can control by FetchType.EAGER). I want to manage the storage for these data differently. Maybe the data is so large that I need to partition the backing tables. Hibernate seems to be saying that these situations are for those stupid old "legacy" applications. Just let your object model define the data model! What could possibly go wrong?

My needs aren't legacy needs. These are the needs of reality.