database_consistency

What the tool checks

database_consistency exists to catch the quiet mismatches that appear between a Rails application and the database that backs it. Its checkers cover a long list of concrete problems. It can find missing null constraints, missing check constraints for numericality validations, missing length validations, and missing presence validations. It looks for missing uniqueness validations and the unique indexes that should back them, missing foreign keys for BelongsTo associations, and missing indexes for HasOne and HasMany associations. It verifies primary key types, flags mismatching primary key and foreign key types, and reports redundant non unique indexes and redundant uniqueness constraints. Enum handling gets attention too: it finds mismatching enum types and values between the database and ActiveRecord enums or inclusion validations, mismatching foreign key cascades, and a redundant case insensitive unique validation option. Boolean fields get a dedicated check for a missing null constraint. The tool also finds broken associations that point at non existent models, models with missing tables, UUID primary keys without an ordering column, and belongs_to associations whose foreign keys lack dependent or on_delete options. Polymorphic association nullability and columns used in find_by calls without an index round out the list. The breadth of these checks means a single run can surface schema problems that would otherwise only appear as confusing runtime errors, which is why the project positions itself as a guard for teams that move fast on their models.

How a check run looks

Using the tool is straightforward for a Rails team. You add the gem to the development group of your Gemfile with require set to false, run bundle install, and then run bundle exec database_consistency. The command prints one line per finding, naming the checker, the result, the model, and the specific column or association involved. A sample run shows entries such as NullConstraintChecker fail User code column is NOT NULL but does not have a validator disallowing nil values, or ForeignKeyTypeChecker fail when a foreign key type does not match the primary key it references. Missing indexes, redundant indexes, view primary keys, and three state boolean problems all surface the same way, so a developer can work through the list top to bottom. Beyond reporting, the project provides auto correction, flexible configuration, a slow start mode that writes TODO files, and support for writing your own custom checker. The example output in the README makes the value clear: many of these issues compile without error and only bite at runtime, yet the gem lists them in seconds. It supports SQLite3, PostgreSQL, and MySQL, and at the time of writing it supported ActiveRecord only. The README links each checker to its own wiki page, so a developer can read the exact rule and the rationale before changing a model or a migration to satisfy it. Because the checks run in seconds and name the model, column, and association for each finding, the gem fits naturally into a pre commit or continuous integration step where a team wants schema and model drift caught before it ships.

Reporting and project backing

The project is distributed as open source under the MIT license and has gathered a sizable following, with 1,191 stars and 65 forks recorded on GitHub and only a small number of open issues. Its README points readers to a wiki for the details of every checker, and it thanks Pennylane for supporting the work. Funding is handled through Open Collective, where individuals can become backers and organizations can become sponsors, with logos shown on the GitHub page. The maintainer also invites contributions and donations, noting that community support is a strong motivation. On the contribution side, bug reports and pull requests are welcomed on GitHub, and the project asks participants to follow the Contributor Covenant code of conduct so the space stays welcoming. A changelog is kept for those who want to track what changed between releases. The combination of a broad checker list, auto correction, and an approachable reporting format is what has kept the gem relevant for teams that want their schema and their models to stay in agreement as the application grows. The maintainer also notes that the gem is greatly supported by Pennylane, and the README keeps a wiki with a page per checker so a team can read the exact rule behind any finding before deciding how to fix it.

Editorial conclusion

database_consistency is written in Ruby, distributed under the MIT license, and had collected 1,191 stars on GitHub as of its last update on 2026-08-24.