Active users, many panels and short auto-refresh intervals multiply the number of queries Grafana must proxy and process. Current docs explicitly treat this combination as a tier-up trigger.
For shared family/team dashboards, wallboards and frequently refreshing operational views.Grafana Hardware Requirements: RAM, CPU, Storage & Dashboards
Learn Grafana hardware requirements for RAM, CPU, SSD, dashboards, alerts, users, databases, rendering and ZimaOS hardware.
Grafana hardware requirements at a glance
Grafana now publishes explicit server sizing guidance. The current Grafana documentation sets a floor of 1 CPU core and 512 MB RAM, then scales hardware according to concurrent users, alert rules, data-source type, dashboards/panels and refresh intervals.
- Official floor
- Current Grafana requires at least 1 CPU core and 512 MB RAM. Grafana itself describes this as an installation/evaluation floor rather than a production target.
- Small deployment
- Current official Small-tier guidance starts at 2 CPU cores, 2–4 GB RAM, 10–20 GB SSD for the database host and one Grafana instance. The tier assumes roughly fewer than 25 concurrent users, 100 alert rules, 5 data sources and 200 dashboards.
- What drives RAM/CPU
- Concurrent active users are the primary driver, followed by alert-rule count/evaluation frequency, proxied data-source behavior, panel count and dashboard refresh interval. Image rendering and many short-interval alert rules are common reasons to move up a tier.
- Database
- Grafana supports SQLite 3, MySQL 8.0+ and PostgreSQL 12+. SQLite is the default and is suitable for local development/small evaluation, but current official docs do not recommend it for production; high availability requires MySQL or PostgreSQL.
- Backends are separate
- Grafana's sizing table covers the Grafana server process only. Prometheus/Mimir, Loki, Tempo/Enterprise Traces and other data sources have separate CPU, RAM, storage and network requirements.
- Best Zima starting point
- ZimaBoard 2 832 already exceeds Grafana's current Small-tier CPU/RAM baseline with 4 cores and 8 GB RAM. Add SSD for persistent Grafana/database data. Move to 1664 or ZimaCube 2 when alerts, dashboards, external databases and other monitoring services share the host.
From official requirements to the right setup
Grafana sizing starts with the official 1-core/512-MB floor, then maps the actual deployment to Small, Medium or Large based on active users, alerting, data sources and dashboard query load.
-
Official requirements
Start from current Grafana server guidance, not old forum posts: 1 CPU core and 512 MB RAM is the installation floor; Small production-like sizing starts at 2 cores and 2–4 GB RAM.
-
Confirm your needs
Classify the real query workload. Count concurrent active users, alert rules and evaluation intervals, proxied SQL data sources, panels per dashboard and refresh intervals rather than using total registered users alone.
-
Leave room to grow
Separate Grafana from its telemetry backends. Prometheus/Mimir, Loki, Tempo/GET, databases and image-rendering workers each need independent capacity; do not add their requirements to the Grafana minimum table and call it one application minimum.
-
Run it on ZimaOS
Run representative dashboards and alerts while monitoring Grafana RAM, CPU, database I/O and data-source latency. If performance is slow, identify whether Grafana, the renderer or the data source is actually saturated before upgrading the server.
Check every playback client
- Peak concurrent active dashboard users
- Number of alert rules and evaluation intervals
- Number and type of data sources, especially proxied SQL sources
- Dashboards, panels per dashboard and auto-refresh interval
- SQLite versus external MySQL/PostgreSQL
- Image rendering and renderer-worker count
- Prometheus/Mimir, Loki and Tempo/GET backend sizing
- Other ZimaOS monitoring and home-server services
Official minimum requirements
Current Grafana v13.1 documentation explicitly publishes both a minimum installation floor and Small/Medium/Large deployment tiers. These current figures supersede old 250–255 MB community/tutorial references.
Use 1 core + 512 MB RAM only as the current Grafana installation/evaluation floor. For an always-on home server with dashboards and alerts, the official Small tier—2 cores + 2–4 GB RAM + 10–20 GB SSD—is the more useful planning baseline. Size telemetry backends independently.
| Requirement | Official minimum | What this supports |
|---|---|---|
| Minimum CPU | 1 CPU core | Current official installation floor. |
| Minimum RAM | 512 MB | Current official installation floor; Grafana's FAQ describes it as an evaluation floor rather than a production target. |
| Small tier | 2 cores, 2–4 GB RAM, 10–20 GB SSD | One instance; official starting point for fewer than roughly 25 concurrent users, 100 alert rules, 5 data sources and 200 dashboards. |
| Medium tier | 4–8 cores, 8–16 GB RAM, 20–50 GB SSD | Current guidance uses two load-balanced instances and external MySQL/PostgreSQL; separate image rendering is recommended. |
| Large tier | 8–16+ cores and 16–32+ GB RAM per instance | Current guidance uses 3+ load-balanced instances, 50+ GB high-IOPS SSD and 10 Gbps or faster networking. |
| Image renderer | Approximately 1 GB RAM per renderer worker | Current official sizing guidance says renderer workers should be separated as deployments grow. |
When to upgrade your hardware
Upgrade Grafana when the workload crosses the current official tier drivers, not simply because the number of stored metrics or logs grows on another backend.
Concurrent users and dashboard refreshes increase query throughput
Alert rules saturate the shared Grafana process
Image rendering or SQL-backed data sources add server-side work
Grafana OSS runs alert evaluation in the same process as the UI and data-source proxy. Large numbers of short-interval rules can consume CPU and degrade dashboard responsiveness.
For monitoring servers with hundreds to thousands of alert rules or sub-minute evaluation intervals.Server-side image rendering can consume about 1 GB per worker, while proxied SQL sources hold server-side query connections. Both can move a deployment above its apparent dashboard-count tier.
For alert screenshots, reports and dashboards backed heavily by MySQL/PostgreSQL/MSSQL.Plan hardware growth with confidence
Grafana scales cleanly when the UI/control process, database, image renderer and telemetry backends are treated as independent resource layers.
Move Grafana data and database to SSD
Current Small-tier guidance assumes SSD on the database host. Responsive storage becomes more important as dashboard, user, alert and configuration state grows.
Use SATA/NVMe SSD for Grafana AppData and database.Move from SQLite to PostgreSQL or MySQL before HA
Current Grafana docs do not recommend SQLite for production and require MySQL/PostgreSQL for high availability.
Reserve RAM and SSD capacity for an external PostgreSQL/MySQL service when the deployment grows.Split image rendering from the Grafana server
Medium and Large guidance moves rendering into a separate process/container, with about 1 GB RAM per worker.
Keep rendering separate before assuming the main Grafana instance needs a much larger server.Scale Prometheus/Loki/Tempo independently
Grafana visualizes and queries external telemetry. The metrics, logs and trace backends may need far more CPU/RAM/storage than Grafana itself.
Choose additional Zima storage/compute for the telemetry backend, not as a Grafana UI requirement.Can it run on ZimaOS?
Grafana is currently available in the ZimaOS App Store under Developer. The current App Store package is Grafana 13.0.1-security-01 and shows a 64 MB minimum-memory/package value, but upstream Grafana now requires 512 MB as its current installation floor.
Install Grafana from the ZimaOS App Store
The current ZimaOS listing is Grafana 13.0.1-security-01 under Developer and exposes Grafana as an observability/dashboard application.
Open Grafana in the ZimaOS App StoreDo not use the ZimaOS 64 MB listing as the sizing baseline
The App Store currently displays Minimum memory 64 MB, but current upstream Grafana documentation requires 512 MB. For hardware planning, the current upstream requirement takes precedence.
Read current Grafana requirementsSize data sources separately
A ZimaOS host may run Grafana beside Prometheus, Loki or another database. Their resource use is separate and can dominate the server even when Grafana remains within the Small tier.
Read Grafana deployment sizing guidanceChoose Zima hardware for your Grafana workload
ZimaBoard 2 832 already exceeds Grafana's official Small-tier CPU/RAM baseline. Larger Zima systems are justified by Medium-tier Grafana, telemetry backends, databases, rendering and the rest of the monitoring stack.
Is Grafana a small home dashboard server, or part of a larger monitoring/telemetry stack?
Small Grafana deployment with modest alerts and data sources
ZimaBoard 2 832 clears the official Small-tier 2-core/2–4-GB baseline. Add SSD for Grafana/database data. Choose 1664 when Grafana shares the host with Prometheus, databases, more alerts or other containers.
- Small Grafana and lightweight monitoringZimaBoard 2 832
- More alerts, databases and co-hosted monitoring servicesZimaBoard 2 1664
Larger monitoring stack, more storage or Medium-like workload
ZimaCube 2 is selected from the combined monitoring/NAS workload. Pro's 16 GB RAM and stronger CPU are more aligned with a single-host Medium-like stack, but official Medium guidance itself assumes two load-balanced Grafana instances.
- Storage-first monitoring and telemetry archiveZimaCube 2 Standard
- Heavier all-in-one monitoring/database stackZimaCube 2 Pro
- Only for independent GPU/AI workloadsZimaCube 2 Creator Pack
Grafana's official tiers are starting points, not guaranteed dashboard/user limits. Data-source latency, query complexity, panel refresh, alerts and renderer workloads can move a deployment to a higher tier.
| Zima hardware | Best for | Example workload | Core configuration | Recommended boundary | Next step |
|---|---|---|---|---|---|
| ZimaBoard 2 832 | Small Grafana deployments and lightweight home monitoring. | Grafana dashboards, modest alerting, a few data sources and lightweight co-hosted monitoring services. |
|
Use SSD rather than relying on eMMC for a growing Grafana/database stack. Prometheus/Loki/Tempo may require more resources than Grafana. | Get Now |
| ZimaBoard 2 1664 | A compact monitoring host with more alerts, external database and additional services. | Grafana plus Prometheus-class monitoring, PostgreSQL, more alerts and a denser container stack. |
|
Do not describe 16 GB as a Grafana requirement; it is for the broader host workload. | Get Now |
| ZimaCube 2 Standard | Storage-first monitoring where local telemetry retention and multi-drive capacity matter. | Grafana plus logs/metrics storage, backups and moderate NAS applications. |
|
Still 8 GB RAM, so choose it primarily for storage rather than memory-heavy Medium-tier Grafana. | Get Now |
| ZimaCube 2 Pro | Heavier single-host monitoring/database stacks with more CPU, RAM and network headroom. | Grafana, PostgreSQL, Prometheus/Loki-class services, more alerts, dashboards and broader home-lab workloads. |
|
Official Medium Grafana guidance assumes two load-balanced instances; one Pro box should not be presented as equivalent to that HA topology. | Get Now |
| ZimaCube 2 Creator Pack | Grafana on a server independently required for local AI/GPU creator workloads. | Grafana plus unrelated GPU/AI services and large storage. |
|
Extreme overkill for Grafana; never recommend it for dashboards, alerts or image rendering alone. | Get Now |
What the Press Says
Highlights from trusted reviewers worldwide.
“ZimaCube 2: Not just another NAS, tested with 25TB storage, local AI agents, 4K transcoding, and real homelab workflows.”Read full review
“The ZimaBoard 2 is a compact x86 server board that can be turned into a mini NAS, home server, media box, or self-hosting hub.”Read full review
“ZimaCube 2: A modern, high-performance NAS with plenty of room to grow—built for users who want more than basic storage.”Read full review
“Coverage focused on ZimaCube 2's open hardware foundation, no monthly fee, and self-hosting flexibility.”Read full review
Loved by the Community
Stories and reviews from people who build with Zima every day.
★★★★★
Zima Blade Little yet Powerful
Maybe I am not digital natives but I live with PCs since 12 years old in 1984 when IBM PC clone come to my home. Many years have passed and many operating system I've tried. For me Zima blade and CasaOS was a quantum leap for home PC enthusiast and server lab machine to make me stay curious and relevant for this era.
★★★★★
Very good!!
I use ZimaCube Pro as 5th Proxmox cluster node. It runs several VMs and containers, including a VM with GPU passthrough to run a self-hosted LLM. A specific LXC container runs a Samba server for NAS capabilities using four of six RAID 6 SATA HDDs with ZFS.
★★★★★
Great innovation for mini server!
It is very useful and makes a powerful mini server for many purposes, including university and college students in engineering and electronics. Thank you so much for making this server.
★★★★★
Avaliação ZimaBoard 2
Construí um servidor de uso pessoal. O desempenho está muito bom e funciona perfeitamente onde quer que eu esteja. A surpresa é não dependermos de grandes estruturas para termos nosso próprio servidor de dados. Como iniciante, estou gostando bastante do ZimaOS, pois ele é simples e eficiente.
Frequently asked questions
Several supplied sources quote much smaller or much larger numbers than current Grafana Server guidance. The difference is mostly age or product scope.
How much RAM does Grafana need in 2026?
Current official Grafana v13.1 documentation sets 512 MB as the minimum installation floor. For a Small deployment, it recommends 2–4 GB RAM with 2 CPU cores and 10–20 GB SSD.
Is 250 MB RAM still enough for Grafana?
Do not use 250 MB as the current minimum. That figure comes from a 2017 Grafana Community reply and predates today's official 512 MB floor and explicit deployment tiers.
Why does one Medium article say 255 MB?
The supplied Medium tutorial reproduces an older 255-MB minimum. Current Grafana documentation now says 512 MB, so the older tutorial figure should be treated as stale.
Does Grafana Enterprise Traces require 16 cores and 64 GB RAM?
Grafana Enterprise Traces (GET) does: its current page requires a managed-Kubernetes deployment, recommends nodes with at least 16 cores/64 GB RAM and 10-Gbps networking. Those requirements are for the trace backend product, not the ordinary Grafana Server UI.
Is the Mintlify Grafana page consistent with current official sizing?
Mostly. It lists 512 MB/1 core as the minimum and 2 cores/2–4 GB/10–20 GB SSD for Small, matching the current official page. Use grafana.com as the authority because the Mintlify domain is a mirror.
What about the 16–32 GB figures in the IIR hardware guide?
The supplied IIR article presents much larger generalized production figures. Current official Grafana sizing is more specific: 16–32+ GB belongs to the official Large tier per instance, while Small starts at 2–4 GB. Therefore large generic numbers should not be used as the baseline for a home Grafana server.
Does Grafana need a GPU?
No dedicated GPU is required for Grafana Server. Image rendering is a separate renderer workload and current docs size it primarily by worker memory, approximately 1 GB per renderer worker.
Can ZimaBoard 2 832 run Grafana?
Yes. Four N150 cores and 8 GB RAM exceed Grafana's official Small-tier baseline. Pair it with SSD storage and size Prometheus/Loki/Tempo or other data sources independently.
What sources and further reading informed this Grafana hardware guide?
The current official Grafana installation page is the primary source and now specifies 1 core/512 MB as the installation floor plus Small, Medium and Large deployment tiers. The supplied Grafana Enterprise Traces page applies to GET, not Grafana Server, and therefore its 16-core/64-GB/10-Gbps requirements are deliberately excluded from the base Grafana requirement. The 2017 Grafana Community forum's 250-MB reference is historical and lower than the current floor. The supplied Mintlify mirror broadly matches current official sizing but remains secondary to grafana.com. The supplied IIR guide was indexed during this audit but the page itself was not reliably fetchable; its search-result summary emphasizes 16–32+ GB, which corresponds more closely to large deployments than a universal baseline. The supplied Medium tutorial uses an older 255-MB figure and is treated as stale against current official documentation.
