The Active Record pattern is described as
An object that wraps a row in a database table or view, encapsulates the database access, and adds domain logic on that data.
It is tightly coupled to the database schema. In other words, decisions that go into designing entities (objects/classes that hold application independent business logic) of your software project affect the database and vice versa.
Ideally, the database is a layer of abstraction lower than your application. What that means is that the decisions of your peristence layer should not affect design decisions of your business logic and vice versa. As an example, you should be able to think through the design decisions of a relational or a non relational database looking at peristence only and not having to wonder how that would affect the rest of your application. This is definitely not true in a conventional rails app, and I imagine, it won’t be true in any application that uses the active record design pattern.
The data mapper pattern on the other hand just maps data to your data to your objects. You can design your entities just as you would in any ruby application without being concerned about how your design decision for entities/models affect the database. You can keep them independent of your database. (At-least that’s my idealized understanding of it). This will increase work for you to do upfront, but will let your app be layered allowing for modularized decisions.
Data mapper project in ruby, ironically, is an implementation of the active record pattern. I am not sure if that was intentional or not. So, in order to implement the data mapper pattern, data-mapper2 was envisioned and worked on. It has been renamed to Ruby Object Mapper since. It’s currently being used in production in some apps. Piotr Solnica is leading the project and it's 1.0 release is estimated to be in September 2015!
I found this tutorial on ROM to be very enlightening: http://rom-rb.org/tutorials/todo-app-with-rails/