Server Sizing & Hardware Requirements
How much CPU and memory the Athena server needs, and when to move from the built-in SQLite database to PostgreSQL, based on the size of your fleet. The recommendations come from load tests against a real Athena server. Each row says whether it was measured or is an estimate. Only the measured rows have test results behind them.
Hardware requirements by fleet size#
| Fleet size | CPU | RAM | Database | Basis |
|---|---|---|---|---|
| Up to 250 agents | 1 core @ 3.0 GHz+ (2019 or newer) | 2 GB | SQLite | Estimate. On a single-core run, 500 steady agents used about 20% of an older 2.3 GHz core from 2016. |
| Up to 500 agents | 2 cores @ 3.0 GHz+ | 4 GB | SQLite | Measured on 2 cores @ 3.25 GHz: 500 agents + 10 console users, 0% errors, every latency threshold passed, about 37% CPU and 0.4 GB RAM. |
| Up to 2,000 agents | 2 dedicated cores @ 3.25 GHz+ | 4–8 GB | SQLite for steady fleets. Use PostgreSQL if you expect mass reconnects. | Measured on 2 cores @ 3.25 GHz: 2,000 agents + 20 console users, 0% errors, REST p95 273 ms, 1.0 GB RAM. When all 2,000 reconnect at once, performance drops for a few minutes (see below). |
| 2,000–5,000 agents | 4 cores @ 3.0 GHz+ | 8–16 GB | PostgreSQL | Estimate, not tested. |
| Over 5,000 agents | 8+ cores @ 3.0 GHz+ | 16 GB+ | PostgreSQL on its own host | Estimate, not tested. |
Disk space for the database, uploaded packages, logs and backups depends on what you keep, so it is not part of this table. For what each data directory holds, see Data Directories & Backup. To move off SQLite, see PostgreSQL Database.
Clock speed is only a fair comparison between CPUs of a similar age. The two test servers differed by 1.4× in GHz (2.3 vs 3.25) but by much more in the work each core got done. The newer core (AMD Zen 4, 2023) does more per clock than the older one (Intel Broadwell, 2016), and the older CPU also loses some speed to the Meltdown (PTI) mitigation. As a rule of thumb, count a core from before 2018 at half its GHz.
Dedicated vs shared CPU#
| Shared vCPU | Dedicated vCPU | |
|---|---|---|
| What you get | A slice of a physical core that other tenants' servers also use | A core (or hyper-thread) reserved for you alone |
| Performance | Varies. It slows down when neighbouring servers are busy (“CPU steal”). Burstable types such as AWS t3/t4g and Azure B-series are throttled once their CPU credits run out. | Steady. You get the same performance at any time of day. |
| Examples | DigitalOcean Basic / Regular, AWS t3/t4g, Azure B-series, Hetzner CX/CPX | DigitalOcean CPU-Optimized / General Purpose, AWS c/m families, Azure D/F-series, Hetzner CCX |
| Fine for Athena | Up to about 500 agents, or a lab | Above 500 agents |
In an on-premises or air-gapped installation, your own hardware counts as dedicated. That covers a physical server, or a VM on your own Hyper-V or VMware host, as long as the host is not over-committed. Over-committed means the VMs on the host have been given more vCPUs in total than the host has physical cores.
Why this matters for Athena: the heaviest load comes in a reconnect storm. That is when every agent reconnects at once, for example after a server restart or a network outage. The server needs its full CPU at that moment, and that is exactly when a shared or burstable core may be at its slowest.
Load-test results#
The tests used simulated agents that speak the real agent protocol on port 8444,
and simulated console users browsing the REST API (read-only) on port 8443, all
running against one Athena server. When each simulated agent connects, it sends a heartbeat
with resource metrics and a full inventory snapshot of about 78 KB, the same as a real
agent. The server in the table below had 2 vCPUs (AMD EPYC, Zen 4, 2023, 3.25 GHz base),
7.8 GB RAM and the default SQLite database.
| Run | Agents connected | Agent connect p95 | REST p95 | Errors | Server CPU / RAM peak | Result |
|---|---|---|---|---|---|---|
| Smoke: 5 agents + 1 user | 5 / 5 | 0.73 s | 242 ms | 0% | 29% / 0.4 GB | Pass |
| Load: 500 agents + 10 users, 10 min | 500 / 500 | 0.39 s | 254 ms | 0% | 37% / 0.4 GB | Pass |
| Load: 2,000 agents + 20 users, 15 min | 2,000 / 2,000 | 0.46 s | 273 ms | 0% | 189% while ramping, 65–125% steady / 1.0 GB | Pass |
| Spike: 0 → 2,000 agents at once, 5 min | 2,000 / 2,000 | 11 s | 363 ms (p99 2.3 s) | 0% | 214% / 1.9 GB | Degraded: 4 latency thresholds failed |
CPU is shown out of 200% because the server had 2 vCPUs. About 80 ms of each REST figure is network round-trip time from the test client. Enrollment ran at about 6.5 agents per second (2,021 agents in about 5 minutes) with no failures.
What limits a server#
Reconnect storms on SQLite#
SQLite allows only one writer at a time. When every agent reconnects at once, each one sends its inventory and heartbeats, and those writes queue up behind each other. The CPU stays busy for the whole storm. In the 2,000-agent spike nothing failed, but agents took 8–12 seconds to connect. For a few minutes, the 95th-percentile response time for the dashboard, alerts, agents list and sign-in went above 1 second. If a large fleet will reconnect all at once after a server restart or a site-wide network outage, use PostgreSQL.
Enrollment bursts#
Enrolling an agent costs the server more than anything else that agent does, because the server creates a key pair and signs a client certificate for every agent it enrolls. On a single shared core, enrolling about 25 agents in parallel overloaded the server, and sign-in took up to 7.8 seconds while enrollment was running. On a small server, roll out agents in batches. See Agent Enrollment and AD Agent Deployment.
PostgreSQL, fleets larger than 2,000 agents, and long-running soak tests (4 hours or more) have not been load-tested yet. Treat the rows above 2,000 agents as starting points, and watch the server on Server Health & Monitoring after rollout.