It's always a hassle to configure database settings, create tables... Most of the time, when I'm trying samples from books I'm reading, I'm using in-memory tables with hsqldb. I understand that samples should work regardless of the database being used, but which database are you using in your samples ?
We've elected to use an in-memory database for all of the examples in the book so that the example code is as self-contained as possible. Our intention is to keep the prerequisites to a bare minimum so that all you need to run the sample application is JDK5+ and Maven 2. Of course, you'll need Spring Roo and Grails installed for the examples related to those sections of the book. We won't be using any proprietary database features in the examples, so switching databases should be straight forward.
Adding to Brian's point, in-memory databases definitely help make it easier for readers of the book to follow along, since there is no real installation process required. However, one of the benefits of Hibernate is its ability to make your application more agnostic to the database vendor. This is another great feature of ORMs in general, and Hibernate allows you to simply select the dialect that matches your database, drop in the appropriate JDBC jars, and you're ready to go! We recommend using in-memory databases for automated testing, while leveraging a more robust database for staging and production. With Hibernate, however, you don't need to worry too much about slight incompatibilities between one database vendor and another. Instead, you can have environment-specific configuration that uses an in-memory DB for local and/or testing scenarios, while using mySQL, postgreSQL, or oracle in Production. So Hibernate provides you with flexibility and portability without requiring additional code complexity to make this happen.
For some performance problems for example, one should
also dive into the actual database brand's specificities
or, in your (longer) experience, this as well can be handled
at the Hibernate level as well?
Triaging performance problems is dependent on a huge number of factors. My preference is to do all of my development with sql logging enabled so that you can catch silly mistakes early on. When a problem rears its ugly head in production that has gone undetected by my monitoring tools, I don't want to risk adding any more overhead by messing around with my application configuration until I've tracked down a decent lead. If I suspect the persistence tier is involved, I tend to look at my application caches first and then go to the database to get more intel; which queries are being executed the most, are there long running queries, etc, etc. From there you can determine whether you should be making optimizations within your database or whether you should be diving into your Hibernate configuration.