Overview

Rails Pulse stores all monitoring data — requests, SQL queries, routes, and background jobs — using standard ActiveRecord models. It supports the three most common Rails database adapters:

Rails Pulse stores its data in whichever database your app already uses. No additional database software is required.

SQLite

SQLite is the default Rails database and works well for Rails Pulse in development and small production deployments.

Good fit when:

• Running a low-traffic app (< 1,000 RPM)
• Single-server deployment
• Using SQLite as your main application database
• Getting started quickly

Limitations:

• No concurrent write support — high request volumes can cause lock contention
• Not suitable for multi-server deployments sharing a single database file

Performance overhead: ~4–6ms per request (see Performance Impact)

PostgreSQL

PostgreSQL is the recommended database for production Rails Pulse deployments. It handles concurrent writes well and scales comfortably with traffic growth.

Good fit when:

• Running a production application
• Expecting moderate to high traffic (1,000–10,000+ RPM)
• Using multi-server or containerized deployments
• You want robust query performance for the dashboard

Performance overhead: ~5–6ms per request

# config/database.yml (separate database example)
production:
  rails_pulse:
    adapter: postgresql
    database: myapp_rails_pulse_production
    username: rails_pulse_user
    password: <%= Rails.application.credentials.dig(:rails_pulse, :database_password) %>
    host: localhost
    migrations_paths: db/rails_pulse_migrate
    pool: 5

MySQL / MariaDB

MySQL is fully supported and a good choice if your application already runs on MySQL infrastructure.

Good fit when:

• Your app already uses MySQL and you want Rails Pulse data co-located
• Your team has existing MySQL expertise and tooling

Limitations:

• MySQL is excluded from Rails Pulse’s CI test suite (tested locally only) due to occasional flakiness in CI environments. It is production-ready but receives less automated test coverage than SQLite and PostgreSQL.

Performance overhead: ~5–7ms per request

# config/database.yml (separate database example)
production:
  rails_pulse:
    adapter: mysql2
    database: myapp_rails_pulse_production
    username: rails_pulse_user
    password: <%= Rails.application.credentials.dig(:rails_pulse, :database_password) %>
    host: localhost
    migrations_paths: db/rails_pulse_migrate
    pool: 5

Choosing a Database

If you’re unsure which database to use for Rails Pulse data:

1. Use whatever your app already uses — the simplest option. Rails Pulse tables live alongside your application tables with no extra configuration.
2. Use PostgreSQL for a separate database — if you want monitoring data isolated from your main database and expect meaningful traffic.
3. Use SQLite for a separate database — a lightweight option for low-traffic apps that still want isolation.

See Database Setup for instructions on configuring a single or separate database.

Using a Separate Database

Any of the three supported databases can be used as a dedicated Rails Pulse database. This is useful when you want to keep monitoring data isolated, use a different database engine, or take independent backups.

Install with the separate database flag:

rails generate rails_pulse:install --database=separate

Then configure connects_to in your initializer:

RailsPulse.configure do |config|
  config.connects_to = {
    database: { writing: :rails_pulse, reading: :rails_pulse }
  }
end

Full setup instructions are in the Database Setup documentation.

Next Steps

• Database Setup — Single vs separate database setup and configuration examples
• Performance Impact — How database choice affects Rails Pulse overhead
• Standalone Dashboard — Run the dashboard against a dedicated database