The project explicitly calls large-library imports RAM- and compute-intensive. More memory can help when importing a very large existing collection while the browser and other services are also active.
Large pre-existing music collections.Lidarrのハードウェア要件：RAM、データベース、ストレージ、大規模ライブラリ
LidarrのRAM、SQLite/PostgreSQL、ストレージ、スキャン、大規模ライブラリの要件を確認し、適したZimaOSハードウェアを選びましょう。
Lidarr requirements at a glance
Lidarr does not publish one universal always-on CPU/RAM minimum, but its current large-library import guide gives a useful heavy-workload baseline: 4 GB RAM minimum and 8 GB recommended for importing an existing library. Large scans/imports are explicitly described as RAM- and compute-intensive. Normal idle/request automation can be much lighter.
- CPU
- No universal normal-runtime core minimum. Library imports, rescans, metadata refreshes and database work are the CPU-intensive stages.
- RAM
- For large existing-library imports, the current Servarr/Lidarr guide says 4 GB minimum and 8 GB recommended. Do not mislabel this as a universal idle-runtime floor.
- Database
- Lidarr uses SQLite by default and now documents PostgreSQL configuration as an option. Database/appdata storage should be local and reliable.
- Storage
- Music media can live on large HDD storage, but Lidarr appdata/database benefits from local SSD/NVMe. Large libraries can stress database and metadata operations even when media playback occurs elsewhere.
- Large library
- Current community reports show performance degradation at hundreds of thousands of tracks even on strong hardware, so app/database behavior and metadata services can become bottlenecks before raw RAM does.
- Best Zima starting point
- ZimaBoard 2 832 matches Lidarr's current 8 GB recommended memory for large imports and is a strong normal starting point. Use 1664/Pro for very large libraries or a larger *Arr/download stack.
From official requirements to the right setup
Lidarr sizing should separate normal automation from first-time import/rescan peaks.
-
Official requirements
Estimate track/album count and whether you are importing an existing library. Large initial imports are the workload for which Lidarr currently publishes 4 GB minimum / 8 GB recommended memory guidance.
-
Confirm your needs
Keep Lidarr appdata/database on local reliable storage. SQLite locking/corruption risk rises when database files are placed on unsuitable network filesystems or touched by unsafe live backup processes.
-
Leave room to grow
Tune refresh/rescan behavior for large collections. Metadata refreshes and filesystem rescans can repeatedly create CPU/database work without improving a stable library.
-
Run it on ZimaOS
Install Lidarr from ZimaOS, run a representative import/refresh, then monitor database latency, CPU, RAM and metadata performance before adding hardware.
Check every playback client
- Existing-library import versus fresh small library
- Track and album count
- 4 GB minimum / 8 GB recommended large-import memory
- SQLite versus PostgreSQL
- Local SSD/NVMe appdata
- Music media storage path
- Refresh/rescan schedule
- Other *Arr and download-client workloads
Official minimum requirements
Lidarr's general system documentation does not define a universal host RAM minimum, but the current importing-existing-library guide gives explicit memory guidance for large imports.
Use 4 GB minimum / 8 GB recommended only for the large-library import workflow it describes. Normal runtime may use less; extremely large libraries may need more and can remain slow for software/database reasons.
| Requirement | Official minimum | What this supports |
|---|---|---|
| Normal-runtime CPU | No universal numerical minimum | Library size, refresh/import work and database load determine demand. |
| Large-library import RAM minimum | 4 GB | Current Lidarr import-guide workload baseline. |
| Large-library import RAM recommended | 8 GB | Current Lidarr import-guide recommendation. |
| Database | SQLite default; PostgreSQL documented | PostgreSQL configuration is supported in current Servarr documentation. |
| SQLite version | 3.9.0 or newer | Current Lidarr system documentation requirement. |
| GPU | Not required | Lidarr manages music metadata/download automation; it does not transcode media. |
When to upgrade your hardware
Upgrade Lidarr when import/database performance or the whole automation stack is actually constrained.
Large initial import exceeds the 8 GB recommended workflow tier
Hundreds of thousands of tracks make UI/database operations slow
The *Arr/download stack competes for appdata I/O and RAM
Recent Lidarr community reports show severe slowdown from roughly hundreds of thousands of tracks, sometimes even with powerful CPUs, lots of RAM and NVMe storage.
Very large collectors.Prowlarr, Sonarr, Radarr, download clients and Lidarr each maintain databases/scans and can create overlapping disk/CPU work.
All-in-one automated media servers.Plan hardware growth with confidence
Scale Lidarr by improving local database/appdata and reducing unnecessary library work.
Keep SQLite appdata on local SSD/NVMe
SQLite does not behave well when database files are placed on unsuitable network filesystems. Local low-latency appdata reduces locking and latency risk.
Use eMMC/SSD/NVMe locally even if music files live on HDD/NAS storage.Consider PostgreSQL for a deliberately managed large deployment
Current Servarr docs now include PostgreSQL configuration, but migration and operation are more complex and do not automatically make every huge library fast.
Give the PostgreSQL service its own memory, SSD and backup budget.Reduce unnecessary rescans
Lidarr exposes rescan-after-refresh controls. For stable massive libraries, repeated full filesystem scans can create avoidable work.
Tune task behavior before assuming more CPU is required.Back up the database safely
Lidarr's built-in backup covers application config and SQLite data; PostgreSQL needs its own database backup. Live SQLite file copying can interact badly with WAL state.
Store backup copies separately and test a restore.Can it run on ZimaOS?
Lidarr is currently available in the ZimaOS App Store under Media.
Install Lidarr from the ZimaOS App Store
Use the packaged music collection manager with persistent appdata and correctly mapped music/download paths.
Open Lidarr in the ZimaOS App StoreUse the current import guidance for large libraries
The Servarr/Lidarr guide explicitly calls large imports RAM/compute intensive and gives 4 GB minimum / 8 GB recommended memory.
Read Lidarr existing-library import guidanceTreat PostgreSQL as an optional advanced database path
Current Lidarr documentation includes PostgreSQL setup and separately warns that built-in backup does not back up a PostgreSQL database.
Read Lidarr PostgreSQL setupChoose Zima hardware for Lidarr
Lidarr's heaviest predictable workload is large-library importing/scanning rather than music playback.
Is this a normal music library or a very large existing collection/import?
Normal or moderately large library
ZimaBoard 2 832 meets the project's current 8 GB recommended memory tier for large imports.
- Normal Lidarr serverZimaBoard 2 832
- Larger library / more *Arr containersZimaBoard 2 1664
Very large library and broader media stack
Use stronger CPU/storage and 16 GB RAM for database/import headroom, while recognizing software/database scaling can still dominate.
- Large multi-drive music serverZimaCube 2 Pro
No fixed track count or scan time is guaranteed. Metadata service health, database choice, library organization, storage latency, task settings and companion apps all affect performance.
| Zima hardware | Best for | Example workload | Core configuration | Recommended boundary | Next step |
|---|---|---|---|---|---|
| ZimaBoard 2 832 | A normal Lidarr server and large-library imports within the current recommended RAM tier. | Music automation, metadata, scans and companion downloader integration. |
|
8 GB meets current large-import guidance but huge libraries may still be slow for software/database reasons. | Get Now |
| ZimaBoard 2 1664 | A larger Lidarr library plus more *Arr/download services. | More memory headroom for imports, databases and overlapping containers. |
|
The N150 remains a 4-core CPU; very large metadata/database work can still become CPU-bound. | Get Now |
| ZimaCube 2 Pro | A large all-in-one music automation/storage server. | Large Lidarr collection, more services, multi-drive media and faster appdata storage. |
|
Choose SSD/NVMe for Lidarr database/appdata; HDD capacity alone does not fix database latency. | 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
FAQ topics follow query fan-out around the current 4 GB/8 GB import guidance, very large music libraries, SQLite/PostgreSQL, network appdata and SSD use. Reddit Lidarr discussions were used to identify current large-library pain points.
How much RAM does Lidarr need?
There is no universal normal-runtime RAM minimum, but the current Lidarr large-library import guide says 4 GB minimum and 8 GB recommended for importing an existing library.
Is 8 GB RAM enough for Lidarr?
It meets the project's current recommended memory for large existing-library imports and is more than enough for many normal deployments. Very large libraries can still be slow for database/application reasons.
Why does Lidarr get slow with hundreds of thousands of tracks?
Recent community reports show that huge libraries can become slow even on NVMe storage and powerful hosts. Database queries, metadata operations and application scaling can dominate beyond raw RAM/CPU.
Should Lidarr use SQLite or PostgreSQL?
SQLite remains the simpler normal path; current Servarr docs also provide a PostgreSQL setup. PostgreSQL may help some managed/large deployments but adds migration, tuning and separate backup complexity.
Can Lidarr /config be stored on an NFS or SMB share?
It is a poor choice for SQLite appdata. SQLite locking/WAL behavior can cause performance or corruption problems on unsuitable network filesystems; keep the database on local storage.
Does putting Lidarr appdata on SSD help?
Yes, especially for database queries, imports and refresh operations. Music files can remain on HDD storage while Lidarr's database/config stays on faster local SSD/NVMe.
Can ZimaBoard 2 832 run Lidarr?
Yes. Its 8 GB RAM matches Lidarr's current recommended memory for large imports and its N150 is ample for many normal music automation workloads.
Do I need a GPU for Lidarr?
No. Lidarr manages music metadata, downloads and organization; it does not perform media transcoding that would justify a dedicated GPU.
What sources and further reading informed this Lidarr hardware guide?
Current Servarr/Lidarr import documentation provides the 4 GB minimum / 8 GB recommended heavy-import guidance. System and PostgreSQL pages define SQLite and database behavior. Recent Reddit discussions were used for query fan-out around hundreds-of-thousands-track slowdown and SQLite locking, while ZimaOS confirms the current Media app.
