Balis 情報マガジン

databaseyml

📅 October 29, 2026📖 Verified Publication
```html database.yml Explained: The Complete Rails Database Configuration Guide (2025)

database.yml Explained: The Complete Rails Database Configuration Guide

If you've ever opened a Rails project and stared at config/database.yml wondering why your app refuses to connect to the database, you are not alone. This single file controls every database interaction your application makes — and getting it wrong produces some of the most frustrating errors in the Ruby ecosystem. This guide solves every real problem developers face with database.yml, from basic setup to multi-database architecture, in a practical Q&A format.


Key Takeaways

  • database.yml is the central configuration file for all database connections in a Rails application. It lives at config/database.yml.
  • The three default environments — development, test, and production — each require separate database definitions.
  • Most connection errors are caused by missing credentials, wrong adapters, or environment variable references that aren't loaded at boot.
  • Modern Rails (7.1+) supports multiple primary databases natively, making multi-tenant and sharded architectures far simpler.
  • Never commit database.yml to source control. Use environment variables or secrets managers to keep credentials safe.

What Is database.yml and Why Does Every Rails App Need It?

The Short Answer

database.yml is a YAML configuration file that tells Rails which database engine to use, where to find it, and what credentials to present when connecting. Rails reads this file at boot time and builds its ActiveRecord::Base connection pool from the definitions inside.

What Happens If You Delete It?

Rails will raise a ActiveRecord::AdapterNotSpecified error immediately on any database query. Model operations, migrations, and even rails console will fail before they start. The file is not optional — it is the foundation of data persistence in your application.

Where Exactly Does It Live?

By convention and requirement, it sits at config/database.yml relative to your Rails root. Rails uses Rails.root.join("config", "database.yml") internally. Moving or renaming this file breaks the default loading path and requires additional configuration to fix.


How to Configure database.yml for Your First Time

PostgreSQL (Most Common Production Choice)

default: &default
  adapter: postgresql
  encoding: unicode
  pool: 25
  host: localhost
  port: 5432
  username: <%= ENV['DB_USER'] %>
  password: <%= ENV['DB_PASSWORD'] %>

development:
  <<: *default
  database: myapp_development

test:
  <<: *default
  database: myapp_test

production:
  <<: *default
  database: myapp_production
  host: db.example.com

MySQL / MariaDB

Replace adapter: postgresql with adapter: mysql2 and adjust the socket or host settings accordingly. MySQL also requires explicit collation and charset settings in most production deployments.

SQL Server

Use adapter: sqlserver and reference the sqlserver gem. Connection strings often require a dataserver parameter instead of host.


database.yml vs .env: Where Should Credentials Live?

This is one of the most debated topics in the Rails community. Here is the definitive breakdown:

Factor database.yml (ERB) .env File Secrets Manager
Security ✅ Credentials never stored in file ⚠️ Must be in .gitignore ✅ Highest security
Local Setup ✅ Simple, works out of the box ⚠️ Requires dotenv gem ❌ Overhead for local dev
AWS / Heroku / Cloud ✅ Works with runtime env vars ❌ Not available in most PaaS ✅ Best practice
Multi-environment ✅ Single file, all envs ⚠️ Needs per-env files ✅ Per-environment support
Team Onboarding ✅ Clone and run ⚠️ Copy .env.example ❌ Extra setup required

Verdict: Use ERB interpolation with ENV variables in database.yml for production and PaaS deployments. For local development, use inline credentials or a .env file with .gitignore protection. For enterprise deployments, combine both with a secrets manager like AWS Secrets Manager, HashiCorp Vault, or Heroku Config Vars.


Problem-Solver Q&A: Fixing the Most Common database.yml Issues

Q1: "FATAL: password authentication failed for user" — What Is Wrong?

This error means Rails successfully reached the database server, but the credentials in database.yml are rejected. Check these in order:

  1. Verify the username value matches an actual PostgreSQL/MySQL user.
  2. Check that the password is correct — note that ENV variables are evaluated at boot, so if the env var is empty or undefined, Rails sends an empty password.
  3. Confirm the user has permission to connect to the specified database name.
  4. On PostgreSQL, check pg_hba.conf — the server may reject md5 or scram-sha-256 authentication methods for your user.

Q2: "PG::ConnectionBad: could not connect to server" — Connection Refused

The OS cannot establish a TCP connection to the database host. This is rarely a database.yml syntax error. Causes include:

  • The database server is not running (brew services start postgresql or systemctl status postgresql).
  • The host or port in database.yml does not match the actual server.
  • A firewall is blocking the connection (common on cloud instances and Docker networks).
  • You are using localhost but the database runs in a container — use the container name or bridge IP instead.

Q3: "Could not find a database.yml entry for RAILS_ENV=test"

Rails strictly validates that every running environment has a