How to Clean Up Your Rails Logs: Ignoring Benign SQL Warnings

Introduction

Database warnings are a fact of life in production systems. They’re not errors—the query executes successfully—but they signal something worth investigating. The problem is that when warnings accumulate, they become noise. We end up ignoring them entirely, which defeats the purpose. Rails 7.1 introduces a pragmatic solution: the ability to selectively ignore SQL warnings using error codes.

The Problem

Before this change, Rails treated SQL warnings as a binary concern i.e either we saw them all, or we didn’t.

Consider a typical production scenario: we’re running an upsert operation that occasionally triggers a duplicate key warning. It’s expected behavior and the application handles it gracefully. But every time it happens, the warning appears in our logs and monitoring systems. Over time, these warnings become baseline noise. When a real problem occurs a warning that indicates a schema issue or a query performance regression, it gets lost in the signal-to-noise ratio.

Rails had no granular control over warnings. We couldn’t say “ignore this specific warning, but alert me on that one.” It was all or nothing. We worked around this by suppressing warnings at the database level (risky), filtering logs after the fact (brittle), or simply accepting the noise.

Introducing Controlled Warning Suppression

Rails 7.1 changes this by introducing config.active_record.db_warnings_ignore, a configuration option that lets us specify which warnings to suppress. The key insight is that we can identify warnings by their error codes, a standardized way that databases communicate what went wrong.

The configuration accepts three types of values as below:

Strings: Exact error code matches (e.g., "1062" for MySQL duplicate key)
Regexes: Pattern-based matching for related warnings
Arrays: Multiple codes or patterns

This gives us surgical precision. We can ignore the warnings we’ve decided are safe while keeping visibility into everything else.

Now let’s look at how this works in practice.

Ignoring a MySQL Duplicate Key Warning

MySQL error code 1062 indicates a duplicate entry for a unique key. In an upsert scenario, this is expected.

# config/environments/production.rb

config.active_record.db_warnings_ignore = ["1062"]

Now when we run an upsert that triggers this warning, it won’t appear in our logs or monitoring systems.

User.upsert({ email: "[email protected]", name: "John" })
# Warning suppressed if it's error code 1062

Ignoring PostgreSQL Warning Classes

PostgreSQL uses warning classes instead of numeric codes. We can match these with regex.

# config/environments/production.rb

config.active_record.db_warnings_ignore = [/^0A000/] # PostgreSQL: Feature not supported

Pattern-Based Suppression

For more complex scenarios, we might want to ignore a family of related warnings.

# config/environments/production.rb

config.active_record.db_warnings_ignore = [
  "1062",           # MySQL: Duplicate entry

  /^0A000/,         # PostgreSQL: Feature not supported

  /^42P01/          # PostgreSQL: Undefined table

]

Real-World Use Cases

Upserts trigger duplicate key warnings—expected behavior we can safely ignore. Legacy databases produce harmless warnings about deprecated syntax or unused indexes. Shared database environments generate warnings from other applications’ schemas that don’t apply to us.

# config/environments/production.rb

config.active_record.db_warnings_ignore = [
  "1062",  # MySQL: Duplicate entry (expected in upserts)

  "1265"   # MySQL: Data truncated (expected in ETL)

]

Pro Tip: When NOT to Ignore Warnings

Only ignore warnings we’ve explicitly decided are safe. Don’t suppress schema migration issues, performance regressions, or data integrity concerns these deserve attention. Document why we’re ignoring each warning and revisit these decisions periodically. Keep warning configurations in version control and document decisions with comments. In shared database environments, coordinate with other teams before suppressing warnings that might affect shared schemas.

Conclusion

Rails 7.1 gives us a practical tool for managing database warnings in production. By allowing selective suppression based on error codes, we can keep our logs clean and our monitoring systems focused on what matters. The key is using this power thoughtfully—suppressing only the warnings we’ve explicitly decided are safe, while maintaining visibility into everything else. This change reflects a mature approach to observability: not eliminating all noise, but being intentional about which signals we choose to ignore. In production systems, that kind of control is invaluable.