Size a self-hosted instance

Measure application, PostgreSQL and disk usage under your own traffic before choosing a server.

Measure a representative workload instead of estimating capacity from event counts alone.

Run Supermetry with the same retention, replay, and tracker options you plan to use in production.
During a normal traffic period, record the binary’s resident memory and CPU usage.
Terminal window
```
ps -o pid,%cpu,rss,etime,cmd -p "$(pgrep -xo supermetry)"
```
For Docker, measure both application and database containers.
Terminal window
```
cd /opt/supermetry
docker compose stats --no-stream supermetry postgres
```

Record PostgreSQL database size and current connections.

sudo -u postgres psql -d supermetry -c \
  "SELECT pg_size_pretty(pg_database_size(current_database())) AS database_size;"
sudo -u postgres psql -d supermetry -c \
  "SELECT count(*) AS connections FROM pg_stat_activity WHERE datname = current_database();"

Measure writable storage, including replay files when local replay storage is enabled.
Terminal window
```
sudo du -sh /var/lib/supermetry
df -h /var/lib/supermetry
```
Repeat the measurements during peak ingestion and a long-range dashboard query. Leave headroom for PostgreSQL maintenance, database growth, backups, and replay spill files.
Watch Data health for queue depth, rejected events, and day-close lag after moving to the chosen server.

What you should see: you have peak CPU, memory, database, and disk measurements from your own workload, with no sustained health warnings.

Size a self-hosted instance

Related