Ask A Question


You’re not receiving notifications from this thread.

Audited vs papertrail gem for auditing table changes?

eren asked in Rails

I'm currently looking to use either one of these two for auditing changes made by specific user roles on a rails 6 ecommerce app using mysql. They both seem similar and I'm currently leaning towards papertrail due to the more frequent updates, but I was curious if there is any specific advantage of using one over the other(performance, ease of use...etc) or anyone knows of any pros/cons that stick out.

Would be keen to know if people have used any other gems that seemed good as well.


They are kind of similar. I think that the "main" draw back I've read regarding Papertrail is that it is storing the user ID as a string... so when you do a lookup you have to convert it back to a int.

Did you decide which one to use for your project? If yes, what were you key drivers?


I'm literally just looking at this myself and this thread is all I can find on the topic of audit logging on gorails. This is my first draft, meaning I could've missed or misunderstood something when looking over these gems.

Audited: simple and easy to implement

  • 20M downloads on rubygems
  • source has fewer forks, might indicate fewer changes needed
  • tested with latest-ish major versions of rails and ruby, still trailing behind, possibly for backward compatibility Papertrail: simple and easy to implement with a well defined pathway towards more complex scenarios
  • 800k downloads on rubygems
  • source has more forks, might indicate more changes are needed
  • increase in logical and code complexity when deviating from the default
  • up to date with major versions of ruby and rails
  • readme tells of a breaking change in its history, you may run across older apps pinning an older version of the gem

Audited: one table for all audit records

  • easier for full app audit reporting, can still easily extract per model audits using the type column
  • could be a large table over time Papertrail: one table per model suffixed with "#{Model.table_name}_versions"
  • easier for per model reporting/display
  • isolates table growth to know high use models
  • more cumbersome to combine audit logging across multiple tables

Audited: stores attribute changes

  • smaller disk footprint
  • inherently limits historical view of an object
  • requires walking/merging changes to show full history
  • model changes are easier to traverse history over time
  • current version is in the model's table and must be looked up there Papertrail: (now) stores full changed version of object
  • can delete any timeframe and recreate the original version of the object
  • easily shows full history
  • model changes will require more complex code to traverse history over time
  • can't find where a current version is stored but you can call a method and get it from the gem regardless

Audited: can implement undo feature

  • requires (MORE) code to walk back through history merging changes Papertrail: versions allow easy implementation of an undo feature
  • requires (LESS) code to walk back through history merging changes

Audited: reasonably documented considering its simplicity, missing examples for common modifications
Papertrail: extremely well documented, almost suspiciously so

Both can be turned off or on at will.
Both can specify which attributes to log.
Both can specify which actions to log.
Both automatically log the user responsible using current_user, probably because of the popularity of Devise.
Both offer configuration locally per model and globally through initializers, Papertrail offering more options.


If your app needs simple audit logging where deviations from the default of the gem should be done simply, you're probably better off with the audited gem with a known cost of needing to engineer different behavior. If your app needs a robust undo feature or you have models you know are modified frequently that requires faster access to a previous version, you're probably better off with Papertrail with a known higher cost of dealing with alterations of the gems behavior and possible breaking changes to the model's structure as the audit history grows (you can optionally migrate a data change with the model change). One option might be to start an app's lifecycle with audited and switch to papertrail at the point it outgrows a single table audit log or needs a robust undo feature, making the added costs of multiple database tables marginal/acceptable.

Caveat: Neither inherently supports I18n. If that's necessary in the audit log context, you may want to try something like public_activity as I18n is built in and the gem has about 9M downloads on rubygems. However, that gem's intent is a bit different than specifically audit logging. (see it's readme)


For a simple audit log: Audited
For reification(undo) and diffing: Papertrail
For (simple) audits with internationalization built in: PublicActivity

Given Chris's experience, I'd defer to his opinion over mine. Maybe he'll do a video on comparing these and have a different perspective than I have? I hope my review helps others chose the right option for heir application. There are of course other gems for audit logging too.


Wow, my apologies to everyone for the formatting. The carriage returns were ignored here and I don't know why. Look for "Papertrail: " concatenated after "Audited: " in the first 3 sections for its specifics.


Both PaperTrail and Audited are popular gems for auditing changes in a Rails application. While they serve a similar purpose, there are some differences between them that you can consider:

  1. Functionality: Both gems provide similar functionality for tracking changes, including tracking attribute changes, associations, and associated users. They both offer features like versioning, diffing, and querying historical data.

  2. Ease of Use: Both gems are relatively easy to set up and use in a Rails application. They provide straightforward APIs for tracking changes and retrieving audit data.

  3. Performance: Performance can be a consideration when choosing an auditing gem, especially for high-traffic applications. PaperTrail has a reputation for being faster and more optimized for performance, especially when dealing with large datasets. Audited, on the other hand, may have slightly more overhead due to its implementation.

  4. Community and Maintenance: PaperTrail has a larger user base and a more frequent update cycle, which can be advantageous in terms of community support, bug fixes, and ongoing development. Audited is also actively maintained but may have a smaller community and update frequency compared to PaperTrail.

Join the discussion
Create an account Log in

Want to stay up-to-date with Ruby on Rails?

Join 82,969+ developers who get early access to new tutorials, screencasts, articles, and more.

    We care about the protection of your data. Read our Privacy Policy.