Rails DB: Rails Database Viewer and SQL Query Runner

Why Rails DB Exists Inside a Rails Application

Rails DB addresses a familiar development problem: application records and database structure are often inconvenient to inspect through Rails consoles or generic database clients. It mounts a web interface into the Rails application, where developers can browse tables, inspect schemas and indexes, edit or delete records, run SQL, examine query plans, and export data. The intended audience is primarily Rails developers who already have access to the application's ActiveRecord configuration and want database inspection without moving to a separate administration client.

The project supports PostgreSQL, MySQL, and SQLite according to the README. It uses ActiveRecord, so the documentation says it may also work with other adapters, although those adapters are not confirmed. That distinction matters. Explicit database support is documented, while compatibility with an arbitrary ActiveRecord adapter should be treated as unverified until it is checked against the application's database stack.

The feature set extends beyond a read-only schema browser. The README lists sorting, multiple filters, SQL execution, query autocomplete, query history, EXPLAIN output, CSV and Excel export, SQL file import, table allowlists and blocklists, record deletion, and table truncation. This makes Rails DB useful for exploration and targeted data maintenance, but it also means that access control is a central deployment concern rather than an optional detail.

The Rails Engine and ActiveRecord Data Path

Rails DB is distributed as a Ruby gem despite the repository's primary-language classification as JavaScript. Its visible integration point is a Rails engine mounted at `/rails/db`. Automatic route mounting is enabled by default, so adding the gem can make the interface available under that path without requiring an application developer to edit `routes.rb`.

The documented data path depends on ActiveRecord. The project presents table content, schemas, and indexes, while SQL execution and EXPLAIN operate through the connected database. In standalone mode, the README says `railsdb` and `runsql` can use the application's `config/database.yml`, allowing database inspection without adding Rails DB to the application Gemfile. The repository includes `bin/`, `app/`, `lib/`, and `config/` directories, consistent with a packaged Rails engine that contains routes, controllers, views, assets, and configuration.

The README also documents embedded data tables. Calls such as `rails_db_data_table` can render a full table or selected columns, while `rails_db_data_table_sql` can derive a table from a SQL query. This is a separate feature from the administrative interface: it lets an application expose selected database results inside its own pages.

Several capabilities are explicitly unfinished. Schema visualization and general CRUD operations are marked as future features, although the feature list separately mentions content editing, deletion, and truncation. This inconsistency makes the feature boundary less precise. The documentation supports narrower claims such as viewing and editing table content, but it does not provide a complete current status matrix for every operation.

Installing Rails DB and Opening the Database Browser

For Rails 6 or later, the README recommends adding `rails_db` to the development group. Restricting the dependency to that group reduces the chance that the database interface is bundled into other environments, although it does not replace route and access checks. The documented installation is:

group :development do
  gem 'rails_db'
end

For Rails versions below 6, the README specifies version `2.2.1`. It also says Rails 5.2 may work with the current dependency, but the uncertainty in that note makes version compatibility something to verify before changing an existing application.

Install the bundle with the following command. The reader should expect Bundler to resolve the gem and its dependencies from the application's `Gemfile`.

bundle install

Start the Rails application through its normal development workflow, then open the documented route. At the default Rails development port, the interface is available at `http://localhost:3000/rails/db`, where the README says the database tables and SQL editor should appear.

http://localhost:3000/rails/db

The `text` block above is a URL, not an executable command. If the gem is running in standalone mode, the README gives a different address, `http://localhost:12345/rails/db`. Excel export has one additional documented dependency, `caxlsx_rails`, while CSV export is already included in the advertised capabilities.

Configuring Routes, Access Checks, and Table Visibility

Rails DB generates its own initializer. The README gives the generator command below, which should create `config/initializers/rails_db.rb` for configuration.

rails g rails_db initializer

Automatic mounting is enabled by default. To select a different mount point, the documentation requires setting `automatic_routes_mount` to `false` and adding the engine manually:

mount RailsDb::Engine => '/rails/db', :as => 'rails_db'

Authentication is disabled by default through `http_basic_authentication_enabled`. The initializer also provides username and password settings, table allowlists and blocklists, a general enablement switch, an access verification proc, and sandbox mode. Sandbox mode restricts the interface to read-only queries. That setting is the clearest documented control for reducing data-changing risk.

The documented authorization hook receives the controller and can incorporate application-specific policy objects or role checks. For example, the README shows access being limited to administrators:

config.verify_access_proc = proc { |controller| controller.current_user.admin? }

This approach is flexible but leaves enforcement to the host application. A proc that returns true permits access, so mounting the engine in an exposed environment without a meaningful access check can defeat the convenience of the interface. Table allowlists can also reduce navigation exposure, but they are not a substitute for protecting the whole endpoint because the SQL runner remains part of the mounted interface.

The option descriptions contain a documentation error: `white_list_tables` is described as a blacklist. Its stated purpose, showing only selected tables in the sidebar, indicates that it is intended as an allowlist. That typo reduces confidence in the initializer documentation and should be checked against the generated configuration before use.

SQL Editing, Exports, and Embedded Data Tables

The SQL editor supports statement execution, autocomplete, query history, and EXPLAIN results. These features place Rails DB closer to an administrative console than a conventional ActiveRecord admin screen. Users can move from schema discovery to arbitrary SQL without leaving the Rails application, which is convenient for development and debugging.

Exports are available in CSV and Excel formats according to the README. The Excel path depends on adding `caxlsx_rails`; the README does not document a configuration flag for either format. SQL file import is also listed, but no file size limit, encoding policy, transaction behavior, or validation procedure is provided. Those omissions matter when importing or executing statements against real data.

Rails DB can also render database-backed tables inside application pages. The following ERB selects named columns from `accounts` and applies Bootstrap styling:

<%= rails_db_data_table 'accounts',
                        footer: true,
                        columns: ['id', 'name', 'users_count'],
                        header: true,
                        style: :bootstrap %>

A second helper accepts SQL directly. The query and its options are passed to the helper as shown here:

<%= rails_db_data_table_sql 'select id, name, age from users order by age desc limit 10',
                            footer: false,
                            header: true %>

These examples demonstrate two different trust boundaries. A named table with a fixed column list is easier to constrain than an arbitrary SQL string, but neither helper's authorization behavior is documented in the README. Application developers should not assume that embedding a table helper automatically applies the engine's `verify_access_proc`.

Operational Limits, Compatibility Notes, and Maintenance

The largest limitation is the gap between convenient access control and a complete production database console. HTTP Basic authentication is off by default, automatic routes are mounted by default, and the general access proc returns `proc { |controller| true }`. Those defaults make local development straightforward, but they require review outside a trusted machine.

The project also documents a MySQL-specific dependency note: users may need `gem install mysql2 -v '0.3.20'`. This old, exact version constraint could conflict with an application that already controls its MySQL adapter version. The gemspec and lockfile in the repository may provide more precise dependency information, but the README does not state the complete supported matrix for Ruby, Rails, and database adapter releases.

Older installations require different version choices. The README directs Rails 3.2 and 4.x users to `rails_db` version `1.6`, Rails versions below 6 to version `2.2.1`, and Ruby 1.9.3 users to `rails_db <= 1.6` with `kaminari < 1.0.0`. Ruby 1.9.3 should be considered a historical compatibility path, not a modern deployment recommendation.

The repository is not archived, and its last push was on 2026-06-19. It has no GitHub releases, so there is no published release entry to use as an upgrade checkpoint. The MIT license permits use, modification, distribution, and sublicensing subject to its notice and license conditions, but organizations still need to review dependencies and their own distribution obligations separately.

Rails DB differs from a separately deployed database administration platform by mounting directly inside the Rails engine and reusing ActiveRecord plus `config/database.yml`. That reduces setup during development, but the README does not document formal audit trails, role synchronization, production deployment guidance, query timeouts, or rollback procedures. Those are concrete reasons it may be the wrong choice for regulated or shared administrative access.

Editorial conclusion

Rails developers who need an embedded database inspection tool during development should evaluate Rails DB, while teams that require a separately deployed administration platform, comprehensive audit controls, or documented production-safe operations should look elsewhere first. Before adoption, verify access restrictions, sandbox mode, table allowlists, and your application's authentication integration, especially if the mounted engine could be exposed outside a trusted development environment.

Frequently asked questions

Official sources

1. igorkasyanchuk/rails_db on GitHub
2. Issues
3. License: MIT
4. Project website
5. README