Overview

Rails Pulse stores all monitoring data — requests, SQL queries, routes, background jobs, exceptions, and deployments — 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

Write cost: ~2ms per request on the background writer thread (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

Write cost: a few milliseconds per request on the background writer thread, depending on network latency to the database

# 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
    schema_dump: false
    pool: 5

MySQL

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 has a dedicated CI job but runs a narrower matrix (one Ruby and Rails version) than SQLite and PostgreSQL, which are tested across every supported combination.
• MariaDB is not supported. It does not implement the functional index Rails Pulse needs for route identity, and the gem raises at boot when it detects a MariaDB server.
• mysql2 defaults to prepared_statements: false, so leave capture_actual_sql off unless you have reviewed what your queries contain (see Query Capture).

Write cost: a few milliseconds per request on the background writer thread

# 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
    schema_dump: false
    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