On top of that, you can write your own hibernate xml on which your domain objects depend. If you get too fancy, you'll lose some of your GORM syntactic sugar, but you do have options.
http://stackoverflow.com/questions/425294/sql-database-views... is how you would do direct SQL without GORM, which you would use if you wanted to avoid hibernate entirely. The rest is just command objects - http://grails.org/doc/latest/guide/theWebLayer.html#commandO... - and more importantly, @Validatable. http://grails.org/doc/latest/guide/validation.html#validatio...
(Technically, command objects are a specific function within the controller, but what we're really looking to do is leverage the validation framework.)
It's extra work, but no less so than avoiding an ORM in any framework. But if you can do it in Hibernate, you probably don't need to bother with this most of the time. (When I had to do it, it was to interface with stored procedures.)
http://grails.org/doc/latest/guide/hibernate.html is there if you want to bolt GORM on to legacy classes.
It is trivial to remove the GORM/Hibernate dependencies from Grails.
If you can use No-Sql databases that offer a REST API, all you will need is an additional dependency on Httplib so you can make the calls.
Its fine when it works, but expect inscrutable session flushing errors when you try and flex it too hard.
Sql sql = new Sql(dataSource)
List results = sql.rows('SELECT * FROM mytable WHERE type_id = :type_id', [type_id: id])