Storage & Sizing

This page explains how ServerBee grows its SQLite database over time and gives a 30-day estimate for common 20-server deployments.

Assumptions

All estimates on this page use the same baseline:

• 20 servers
• 30 days from a fresh deployment
• Agents connected continuously
• Agent report interval of 3 seconds
• Server raw metric writer persisting one record per server every 60 seconds
• Default retention:
  • Raw metrics: 7 days
  • Hourly aggregates: 90 days
  • GPU records: 7 days
  • Ping records: 7 days
  • Network probe raw records: 7 days
  • Network probe hourly records: 90 days
  • Service monitor records: 30 days
• Disk I/O enabled and temperature enabled
• No extra growth from audit log bursts, large task output, or unusual Docker event churn unless called out explicitly

What Actually Changes Database Size

Not every capability creates ongoing database growth.

30-Day Sizing Formula

For the assumptions above, the 30-day database size can be estimated with:

S_30d =
70,541,312
+ 48,974,507 × P
+ 2,373,018 × T
+ 1,593,958 × M
+ 41,525,248 × G
+ 285 × E

Where:

• P = number of 60-second ping tasks applied to all 20 servers
• T = total server-target network probe assignments
  • If every server has the same number of targets, then T = 20 × targets_per_server
• M = total 300-second service monitors
• G = total GPU devices
• E = total Docker events written during the 30-day window

Feature Multipliers

These coefficients come from measured SQLite files, not rough guesswork:

Base Monitoring Breakdown

With no extra ping tasks, network probes, service monitors, or GPUs, most of the 30-day footprint comes from the raw metrics table and its index:

Scenario Catalog

The table below lists common 30-day scenarios for a 20-server deployment.

Disk Budget Recommendation

If you are capacity-planning a real deployment, reserve more than the database file itself:

• Use the table above for the base database size
• Add 10% to 20% for WAL growth and transient write bursts
• Add extra space if you expect:
  • large Docker event volume
  • large task output retained in task_results
  • unusually chatty service monitors with large detail_json payloads

Examples:

• A 494.50 MiB medium stack should reserve about 550 MiB to 600 MiB
• A 1.89 GiB heavy stack with GPU should reserve about 2.1 GiB to 2.3 GiB
• A 2.01 GiB maxed practical stack should reserve about 2.2 GiB to 2.5 GiB

Notes and Caveats

• These estimates are for the first 30 days after a fresh deployment. Some hourly tables retain up to 90 days, so a long-running deployment will continue to grow beyond the 30-day numbers shown here.
• The base monitoring estimate already includes traffic_hourly, traffic_daily, and uptime_daily.
• GPU growth is per device, not per server. A server with 4 GPUs multiplies the GPU portion by 4.
• Network probe growth is per assignment, not per target definition. A target shared by 20 servers counts as 20 assignments.
• Docker growth is event-driven. Quiet fleets add almost nothing; container-heavy hosts can add a measurable amount.

Related Docs