add a note about "leaky abstractions"

Author: gavinking

documentation/src/main/asciidoc/introduction/Introduction.adoc

@@ -34,6 +34,21 @@ But if Hibernate is making things more difficult, for some particularly tricky p
 Just because you're using Hibernate for persistence doesn't mean you have to use it for _everything_.
 ====
 
+Let's underline the important point here: the goal of ORM is _not_ to hide SQL or the relational model.
+After all, Hibernate's query language is link:{doc-query-language-url}[nothing more than an object-oriented dialect of ANSI SQL].
+
+.Is Hibernate a "leaky abstraction"?
+****
+Hibernate--and ORM in general--has been accused of being a _leaky abstraction_, that is, of failing to completely hide the underlying relational database.
+Is this true?
+Well, as you can guess from what we've already said, the short answer is: yes, _and that's a good thing._
+Of course, whether you consider an abstraction "leaky" depends on what you think it's trying to abstract.
+Hibernate successfully abstracts many things: variations between dialects of SQL, messy interactions with JDBC, SQL object naming conventions, and so on.
+But it doesn't even attempt to pretend there's anything other than a relational data model underlying all this.
+The simple reason is performance. It's just not possible to <<tuning-and-performance,achieve acceptable performance>> in data access without acknowledging the nature of the underlying persistent representation.
+We're old enough to have seen multiple generations of developer relearn this lesson by experience.
+****
+
 Developers often ask about the relationship between Hibernate and JPA, so let's take a short detour into some history.
 
 [[hibernate-and-jpa]]