Database setup for production in Ruby on Rails - Performance & Optimization

Performance: Database setup for production

HIGH IMPACT

This affects the initial page load speed and ongoing data retrieval performance by how the database is configured and connected in production.

Configuring database connection for a Rails production app

Ruby on Rails

production:
  adapter: postgresql
  encoding: unicode
  pool: 5
  database: myapp_production
  username: myapp_user
  password: <%= ENV['MYAPP_DATABASE_PASSWORD'] %>

PostgreSQL handles concurrent connections efficiently and supports advanced indexing for faster queries.

📈 Performance Gainreduces query latency by 50%+; supports connection pooling to avoid blocking

Configuring database connection for a Rails production app

Ruby on Rails

development:
  adapter: sqlite3
  database: db/development.sqlite3

production:
  adapter: sqlite3
  database: db/production.sqlite3

Using SQLite in production causes slow queries and file locking issues under concurrent access.

📉 Performance Costblocks rendering for hundreds of milliseconds under load; poor concurrency leads to slow LCP

Performance Comparison

Pattern	DOM Operations	Reflows	Paint Cost	Verdict
SQLite in production	N/A	N/A	High server response delay	[X] Bad
PostgreSQL with pooling	N/A	N/A	Low server response delay	[OK] Good

Rendering Pipeline

Database setup impacts the server response time which affects the browser's ability to start rendering the page quickly.

→Server Processing

→Network Transfer

→First Paint

⚠️ BottleneckServer Processing due to slow or blocking database queries

Core Web Vital Affected

LCP

This affects the initial page load speed and ongoing data retrieval performance by how the database is configured and connected in production.

Optimization Tips

1Use a production-grade database like PostgreSQL or MySQL, not SQLite.

2Enable connection pooling to reduce connection overhead and blocking.

3Avoid slow or blocking queries to keep server response fast and improve LCP.

Performance Quiz - 3 Questions

Which database setup is better for production performance in a Rails app?

A Use a flat file database

B Use SQLite for simplicity

C Use PostgreSQL with connection pooling

D Use an in-memory database without persistence

DevTools: Network

How to check: Open DevTools > Network tab, reload the page, and check the Time to First Byte (TTFB) for the main document.

What to look for: A high TTFB indicates slow server response often caused by inefficient database setup.

Practice

1. What file do you edit to configure your production database settings in a Rails app?

easy

A. config/initializers/database.rb

B. config/routes.rb

C. config/environments/production.rb

D. config/database.yml

Solution

1. Step 1: Identify the configuration file for databases

   Rails uses config/database.yml to set up database connections for all environments including production.

2. Step 2: Confirm production environment settings location

   The production database details like adapter, username, password, and host are specified inside config/database.yml under the production section.

3. Final Answer:

   config/database.yml -> Option D

4. Quick Check:

   Production DB config = config/database.yml [OK]

Hint: Production DB settings are always in database.yml [OK]

Common Mistakes:

• Confusing environment config files with database config
• Editing routes.rb for database settings
• Looking in initializers for DB config

2. Which command correctly sets up the production database in Rails?

easy

A. rails db:migrate RAILS_ENV=production

B. rails db:create RAILS_ENV=production

C. rails db:setup RAILS_ENV=production

D. rails db:seed RAILS_ENV=production

Solution

1. Step 1: Understand the purpose of each command

   db:create creates the database, db:migrate runs migrations, db:seed loads seed data, and db:setup does all three: create, migrate, and seed.

2. Step 2: Choose the command that fully prepares the production DB

   To fully prepare the production database, including creation, migration, and seeding, use rails db:setup RAILS_ENV=production.

3. Final Answer:

   rails db:setup RAILS_ENV=production -> Option C

4. Quick Check:

   Full DB setup = rails db:setup [OK]

Hint: Use db:setup to create, migrate, and seed at once [OK]

Common Mistakes:

• Using db:create alone without migrations
• Running db:migrate without creating DB first
• Forgetting to specify RAILS_ENV=production

3. Given this config/database.yml snippet for production:

production:
  adapter: postgresql
  encoding: unicode
  database: myapp_production
  pool: 5
  username: user123
  password: secret
  host: db.example.com

What will happen if you run rails db:setup RAILS_ENV=production?

medium

A. It creates the production database, runs migrations, and loads seed data using the given credentials.

B. It only creates the database but does not run migrations or seed data.

C. It throws an error because the host is not localhost.

D. It ignores the production section and uses development settings instead.

Solution

1. Step 1: Understand db:setup behavior with production config

   The command rails db:setup RAILS_ENV=production reads the production section in database.yml and uses those credentials to create the DB, run migrations, and seed data.

2. Step 2: Confirm host usage and environment selection

   Using a remote host like db.example.com is valid if accessible. The command will not default to development but use production as specified.

3. Final Answer:

   It creates the production database, runs migrations, and loads seed data using the given credentials. -> Option A

4. Quick Check:

   db:setup uses production config fully [OK]

Hint: db:setup uses production config fully, even remote hosts [OK]

Common Mistakes:

• Assuming db:setup only creates DB without migrations
• Thinking host must be localhost
• Forgetting to specify RAILS_ENV=production

4. You run rails db:setup RAILS_ENV=production but get a connection error. Which is the most likely cause?

medium

A. You ran the command without RAILS_ENV=production.

B. The config/database.yml production section has wrong credentials or unreachable host.

C. The production database already exists.

D. You forgot to run rails db:migrate first.

Solution

1. Step 1: Analyze connection error causes

   Connection errors usually mean the app cannot reach the database server or the credentials are invalid.

2. Step 2: Check command and environment usage

   Running rails db:setup creates and migrates the DB, so missing migrations or existing DB are unlikely causes of connection errors.

3. Final Answer:

   The config/database.yml production section has wrong credentials or unreachable host. -> Option B

4. Quick Check:

   Connection error = wrong credentials or host [OK]

Hint: Connection errors usually mean bad credentials or host [OK]

Common Mistakes:

• Assuming migrations cause connection errors
• Ignoring environment variable in command
• Thinking existing DB causes connection failure

5. You want to securely manage your production database credentials without hardcoding them in config/database.yml. Which approach is best practice?

hard

A. Use environment variables referenced in database.yml for username and password.

B. Store credentials in plain text inside database.yml but restrict file permissions.

C. Commit encrypted credentials directly in database.yml without decryption setup.

D. Remove username and password from database.yml and rely on default system user.

Solution

1. Step 1: Understand secure credential management

   Hardcoding sensitive info in files is risky. Using environment variables keeps secrets out of code and config files.

2. Step 2: Confirm best practice in Rails

   Rails supports referencing environment variables in database.yml like <%= ENV['DB_USERNAME'] %> for secure, flexible credential management.

3. Final Answer:

   Use environment variables referenced in database.yml for username and password. -> Option A

4. Quick Check:

   Env vars for DB credentials = best practice [OK]

Hint: Use ENV vars in database.yml to keep credentials safe [OK]

Common Mistakes:

• Hardcoding passwords in config files
• Committing encrypted data without decryption
• Relying on system defaults without credentials