Pi-hole FTL Memory & Blocklist Calculator
Estimate the RAM footprint of the FTL engine from the number of blocked domains you plan to load and your daily query volume, then map that to a host memory tier.
How this estimate is calculated
The figure is arithmetic, not a measurement of your install. It applies three rounded constants chosen to be conservative: a fixed base footprint for the resolver process, a per-domain cost that scales with the size of the gravity list, and a per-query cost for the recent query history kept in memory for the dashboard. They are rules of thumb, not published figures, and the host RAM tier simply rounds the result up to the next sensible amount of memory to buy.
One caveat the arithmetic cannot capture: the peak is not steady-state resolution, it is the weekly gravity rebuild, when the whole subscribed set is parsed, merged and sorted at once. Hosts with very large lists run out of memory during that step long before they struggle to answer queries, which is why the tier adds headroom rather than matching the estimate.
Treat the output as an order of magnitude — enough to tell a 512 MB decision from a
2 GB one. The authority for your own system is the memory reported by the running
pihole-FTL process on that host. Long-term query
retention is stored on disk rather than in memory, so a long retention window grows the
database file rather than this number.
The published minimum for a Pi-hole host is 512 MB of RAM with 2 GB of free disk space, per the project's prerequisites documentation. This estimator exists because that floor assumes a default install, and a several-million-domain configuration is not a default install.