databaseyml
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, andproduction— 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:
- Verify the
usernamevalue matches an actual PostgreSQL/MySQL user. - Check that the
passwordis correct — note thatENVvariables are evaluated at boot, so if the env var is empty or undefined, Rails sends an empty password. - Confirm the user has permission to connect to the specified
databasename. - On PostgreSQL, check
pg_hba.conf— the server may rejectmd5orscram-sha-256authentication 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 postgresqlorsystemctl status postgresql). - The
hostorportindatabase.ymldoes not match the actual server. - A firewall is blocking the connection (common on cloud instances and Docker networks).
- You are using
localhostbut 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