Using the Grails Object Relational Model tends to work quite well when using conventional, structured data. At that point the type of database you are using, relational or otherwise, doesn't really matter. GORM's dynamic finders [1] are a pleasure to use. Also of note are the way in which one can add custom validation functions [2] or switch between deep and shallow validation on the fly [3], it's cascading behaviour options and lazy and eager fetching options [4]. However, there is at least one reason why one might want to avoid using such a layer, and thus lose access to this functionality.
When writing in a highly iterative manner, as might occur when working on a prototype, it can be of benefit to use a schemaless database like MongoDB. One might find that using a more conventional approach to Grails-based development, with Domain objects that dictate the exact structure your persistent data can have, can take away a lot of the benefits of using a schemaless database, which doesn't care much what structure your data has. Where one does use GORM, things may turn out to be a lot less easy to update or refactor than one had hoped. For one, this requires writing database upgrade scripts, as Grails will complain when handling Domain objects that do not have the expected fields set in the expected manner - and rightly so! Another thing is that some views may have been written in a less flexible way, requiring additional work. This additional work can slow down your progress considerably, and some of the advantages of using GORM don't really surface when writing a prototype.
One might choose to skip creating Domain objects and have a service talk directly to the database instead. This can cut down on the amount of work required when making a change in how data is stored, because your database is schemaless. Just as important is that the related functionality should be written in a modular and layered manner, such that a minimum of code needs to be rewritten.
If you are using MongoDB or a similar database system because of it's schemaless nature, and specifically when you are approaching your project in an agile manner, it may be beneficial to write your own, more flexible ORM layer. Should any views be using that data, try to make sure your views are set up in a flexible manner as well, and that there is a proper separation of concerns.
