All docsSearch docs

Start

  1. 01Getting started
  2. 02Install
  3. 03Tracking

Features

  1. 04The dashboard
  2. 05Goals
  3. 06Short links
  4. 07AI sources and agents
  5. 08Email reports
  6. 09Scheduled check
  7. 10Ask your AI

Reference

  1. 11Performance
  2. 12Configuration
  3. 13HTTP API

Platforms

  1. 14Standalone server
  2. 15PHP
  3. 16WordPress
  4. 17Drupal
  5. 18Craft CMS
  6. 19Python
  7. 20Rails
  8. 21Ruby
  9. 22Go
  10. 23Java
  11. 24.NET
  12. 25Elixir
  13. 26Rust

Trust

  1. 27Privacy

Reference

Performance

Choose storage for your workload and see how fast the dashboard opens on SQLite, Postgres, and MySQL.

Runlight supports SQLite and client/server databases today. Choose storage based on concurrent writes, retained history, and report complexity. Monthly visits alone do not establish a safe capacity limit.

Choose storage

Workload Starting point
One app or server with local persistent storage SQLite, with scheduled rollups enabled
Several app servers or substantial concurrent writes Postgres or MySQL; see the server guide and configuration
About 10 million visits a month Load-test Postgres with your retention, events per visit, and peak traffic before choosing infrastructure
Large analytical scans needing a separate analytics engine Optional ClickHouse support is planned, but is not available yet

SQLite permits one writer per database file. Its deployment guidance explains when a client/server database is appropriate. ClickHouse is designed for analytical workloads; Runlight has no validated ClickHouse capacity threshold or benchmark yet.

Measurements

These are local measurements from October 16, 2026, with the changes since 0.1.7 that the next release carries. They are not release guarantees, and they do not measure ingestion.

The machine was an Apple M4 Max with 36 GiB of memory, running macOS and Node 24. One synthetic site held a year of traffic: 1.0 million visits and 3.1 million events, with four goals and daily rollups built. The same rows went into SQLite, Postgres 16, and MySQL 8.4 on that machine. Each time below is every request the dashboard makes when it opens, sent together as a browser sends them, with warm caches and nothing else writing.

Dashboard view SQLite Postgres MySQL
Last 7 days 0.05 s 0.09 s 0.07 s
Last 30 days 0.07 s 0.07 s 0.06 s
Last 30 days, compared with the 30 before 0.07 s 0.07 s 0.07 s
Last 12 months 0.18 s 0.15 s 0.15 s
Last 30 days, one page 2.9 s 0.6 s 1.7 s
Last 30 days, one channel 1.2 s 1.2 s 1.4 s
Last 12 months, one channel 8.2 s 3.5 s 6.5 s
Last 12 months, one page 19 s 9.1 s 24 s

Without a filter, the totals, the chart, every box, and most goals come from the daily rollups, so a longer range costs little more than a short one. A filter has to read the visits it picks, so filtered views over long ranges are where the database matters most, and where ClickHouse support is meant to help.

Keep reports responsive

Run the scheduled check so daily rollups stay current. Set a suitable retention period in Settings, Data. On SQLite, Runlight gathers the query planner’s statistics again as the data grows, so a large import does not leave reports planning for an empty database. Measure filtered reports, funnels, and comparisons with realistic traffic bursts and simultaneous dashboard users before moving databases.

For a capacity test, record hardware, database version, dataset size, events per visit, retention, rollup state, and query ranges. Measure cold and warm p50/p95 report latency alongside ingestion throughput and errors. Repeat the same workload on candidate databases. ClickHouse setup and comparative benchmarks will be documented when that integration is available.