When active tables/indexes repeatedly miss cache and the server performs avoidable disk I/O, more RAM can improve effective caching. But shared_buffers and OS cache must still be tuned sensibly.
For frequently queried databases whose active data/index set has grown.Hårdvarukrav för PostgreSQL: RAM, CPU, SSD och databaser
Lär dig om PostgresSQL:s hårdvarukrav för RAM, CPU, SSD, shared_buffers, work_mem, samtidighet, databaser och ZimaOS-hårdvara.
PostgreSQL hardware requirements at a glance
PostgreSQL does not have one meaningful universal CPU/RAM/disk minimum for modern self-hosting. Current PostgreSQL 18 documentation focuses on memory, query concurrency, worker processes and I/O configuration because a tiny personal database and a busy analytics/application database can differ by orders of magnitude.
- CPU
- No universal current official core-count minimum is published. CPU demand depends on query complexity, concurrent sessions, index creation, vacuum/maintenance and parallel workers. Parallel queries can multiply CPU and memory use across worker processes.
- RAM
- No universal current whole-server RAM minimum is published. Current PostgreSQL defaults shared_buffers to typically 128 MB, while the official docs say a dedicated database server with at least 1 GB RAM can start around 25% of system memory for shared_buffers.
- Per-query memory
- work_mem is a per-query-operation allowance, not a server-wide pool. Multiple sort/hash operations, concurrent sessions and parallel workers can each use it, so total memory can be many times the configured work_mem value.
- Storage
- Use reliable low-latency storage for active database data and WAL. Capacity must cover database size, indexes, WAL, temporary files, vacuum/maintenance headroom and backups. Modern database sizing should not use the tens-of-megabytes figures from PostgreSQL 6.4.
- ZimaOS package
- The current ZimaOS PostgreSQL package uses postgres:17.4, reserves 2 GB RAM, exposes port 5432 and persists /var/lib/postgresql/data. The 2-GB reservation is a ZimaOS package choice, not a PostgreSQL upstream minimum.
- Best Zima starting point
- ZimaBoard 2 832 is suitable for small personal/app databases when paired with SSD storage and conservative memory/concurrency settings. Choose 1664 for more concurrent services and cache headroom; ZimaCube 2 Pro is better suited to heavier database + storage stacks.
From official requirements to the right setup
PostgreSQL sizing starts with working-set size, concurrent connections and query type, then adds WAL/temporary I/O, indexes, maintenance, backup retention and the applications sharing the database host.
-
Official requirements
Do not start from an ancient fixed 'minimum RAM' number. Current PostgreSQL 18 documentation treats memory as configurable pools plus per-query/per-worker allocations rather than one whole-server floor.
-
Confirm your needs
Estimate active working set and concurrency. shared_buffers is global, while work_mem can be consumed independently by multiple sort/hash operations in many sessions and parallel workers.
-
Leave room to grow
Use local SSD/NVMe for active database data and WAL when performance matters. Plan extra capacity for indexes, WAL, temporary spill files, VACUUM/maintenance and backup copies.
-
Run it on ZimaOS
Test representative reads, writes, indexes, maintenance and backup/restore operations while monitoring cache hit ratio, memory, CPU, I/O latency and temporary-file spill. Tune PostgreSQL before assuming hardware is the only bottleneck.
Check every playback client
- Total database size and active working set
- Peak concurrent connections and connection pooling
- Read-heavy, write-heavy or mixed workload
- shared_buffers, work_mem and maintenance memory settings
- Parallel query and worker-process configuration
- WAL volume, indexes and temporary-file spill
- Backup/snapshot retention and restore window
- Other ZimaOS apps using the same PostgreSQL instance
Official minimum requirements
Current PostgreSQL 18 documentation does not publish one universal CPU/RAM/disk hardware minimum. Its resource guidance instead explains how shared memory, per-query memory and parallel workers scale with the workload.
For modern ZimaOS sizing, treat PostgreSQL as a workload-dependent database engine. The current ZimaOS 2-GB reservation is a reasonable package baseline but is not an upstream requirement. The old PostgreSQL 6.4 disk figures are historical and should never be used for current hardware planning.
| Requirement | Official minimum | What this supports |
|---|---|---|
| Current PostgreSQL | 18.4 documentation current as of this audit | PostgreSQL 18 is the current stable documentation line. |
| CPU minimum | No universal current official core minimum | CPU use depends on sessions, queries, parallelism and maintenance. |
| Whole-server RAM minimum | No universal current official minimum published | Current docs expose memory configuration rather than one system-RAM floor. |
| shared_buffers default | Typically 128 MB | On a dedicated server with at least 1 GB RAM, current docs call about 25% of system RAM a reasonable starting point. |
| work_mem default | 4 MB per query operation | Several operations and sessions can use this simultaneously, so total memory can be many times work_mem. |
| ZimaOS package | PostgreSQL 17.4, 2 GB memory reservation | Current manifest supports amd64, arm and arm64 and persists /var/lib/postgresql/data. |
When to upgrade your hardware
PostgreSQL upgrades should follow measured memory, I/O and concurrency bottlenecks rather than generic database-size thresholds.
The working set no longer fits comfortably in RAM
Concurrent queries multiply work_mem and worker usage
WAL, temporary spill and database I/O saturate storage
Current docs warn that multiple sort/hash operations and parallel workers can each consume work_mem. A server that is stable at low concurrency can therefore hit memory pressure during bursts.
For multi-user apps, analytics and large concurrent queries.Slow storage can bottleneck writes, checkpoints, sorts that spill to disk, index builds and restores. SSD/NVMe often matters before buying many extra CPU cores.
For write-heavy, index-heavy and larger application databases.Plan hardware growth with confidence
PostgreSQL scales best when memory, connection concurrency, WAL/data I/O and backups are treated as separate resource layers.
Move database data to reliable SSD/NVMe
Low-latency storage improves active data, indexes, WAL and temporary-file behavior. The current ZimaOS package persists /var/lib/postgresql/data and should be placed on storage appropriate for the database's importance.
Use SATA/NVMe SSD instead of relying on small onboard eMMC.Tune memory before simply adding RAM
shared_buffers, work_mem, maintenance memory and parallel workers interact. More RAM helps only when configuration and workload can use it safely.
Start conservatively, observe memory/temporary spills, then increase settings with headroom.Use connection pooling when client count grows
PostgreSQL is process-per-connection, and each active session can contribute private memory and query work. Pooling can reduce idle/process overhead and smooth concurrency.
Add a pooler or application-level pooling before treating max_connections as a hardware target.Separate backup/archive capacity from the live database
Database files, WAL and backups have different access patterns and retention needs. Large backup history should not consume all active SSD capacity.
Use ZimaCube 2 multi-drive storage or separate backup targets as retention grows.Can it run on ZimaOS?
PostgreSQL is currently available in the ZimaOS App Store under Developer. The current manifest uses PostgreSQL 17.4 and a 2-GB memory reservation.
Install the current ZimaOS PostgreSQL package
The current manifest uses postgres:17.4, exposes TCP 5432 and persists the data directory to /DATA/AppData/postgresql/data.
Open PostgreSQL in the ZimaOS App StoreTreat 2 GB as package sizing, not the PostgreSQL minimum
The manifest reserves 2048 MB but does not establish a universal PostgreSQL hardware floor. Small databases can run with less; larger concurrent workloads can need much more.
Review the ZimaOS PostgreSQL manifestMove database data off small onboard storage
The current persistent path is /var/lib/postgresql/data. For a durable application database, place it on reliable SSD-backed storage and protect it with tested backups.
Read current PostgreSQL server configurationChoose Zima hardware for your PostgreSQL workload
PostgreSQL can serve tiny home apps or demanding multi-user databases, so the correct Zima hardware depends on active data, concurrency, queries and I/O. ZimaBoard 2 832 is the small-database starting point; 1664 and ZimaCube 2 Pro add more useful headroom as memory and storage demands grow.
Is PostgreSQL backing a few home-server applications, or serving a larger concurrent/data-heavy database workload?
Small personal/home application databases
Start with ZimaBoard 2 832 and put PostgreSQL data on SSD. Its 8 GB RAM leaves room above the current ZimaOS 2-GB reservation for the OS and applications. Choose 1664 when several databases/apps share the host or the active working set grows.
- Small home/app PostgreSQLZimaBoard 2 832
- More databases, cache and concurrent servicesZimaBoard 2 1664
Larger data set, heavier concurrency or storage-intensive database server
Choose ZimaCube 2 when storage architecture and I/O become central. Pro's i5/16GB/10GbE class is more balanced for heavier database + NAS/service workloads. Creator Pack provides no PostgreSQL-specific GPU advantage.
- Storage-first database/NAS serverZimaCube 2 Standard
- Heavier concurrent database and application stackZimaCube 2 Pro
- Only for unrelated GPU/AI workloadsZimaCube 2 Creator Pack
This is a workload guide, not a fixed transactions-per-second or database-size benchmark. PostgreSQL configuration, query design, indexes, connection pooling and storage latency materially affect hardware needs.
| Zima hardware | Best for | Example workload | Core configuration | Recommended boundary | Next step |
|---|---|---|---|---|---|
| ZimaBoard 2 832 | Small personal/application PostgreSQL databases on a compact ZimaOS host. | PostgreSQL for home apps, automation tools and small self-hosted services. |
|
Do not keep an important growing database on small eMMC; use reliable SSD storage and tested backups. | Get Now |
| ZimaBoard 2 1664 | More concurrent application databases and a larger shared service stack. | PostgreSQL plus multiple apps, larger cache/working set and more concurrent connections. |
|
16 GB is not a universal PostgreSQL requirement; upgrade when working set/concurrency justifies it. | Get Now |
| ZimaCube 2 Standard | Storage-first database/NAS systems where capacity and multi-drive layout matter. | PostgreSQL plus larger local datasets, backups and moderate NAS services. |
|
Still 8 GB RAM; choose 1664 instead if memory is the main bottleneck and six bays are unnecessary. | Get Now |
| ZimaCube 2 Pro | Heavier concurrent PostgreSQL plus applications, backups and storage workloads. | Larger working sets, more connections, databases, monitoring and broader homelab services. |
|
Query design, indexes, pooling and storage latency can remain bottlenecks even on stronger hardware. | Get Now |
| ZimaCube 2 Creator Pack | A PostgreSQL host independently required for GPU/AI or creator workloads. | PostgreSQL plus separate local AI/GPU applications. |
|
Extreme overkill for PostgreSQL alone; never recommend for database size or SQL performance by itself. | 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
The supplied PostgreSQL sources span ancient upstream documentation and application-specific vendor sizing. None of those vendor numbers should be promoted into a universal PostgreSQL requirement.
How much RAM does PostgreSQL need?
Current PostgreSQL 18 documentation does not publish one whole-server RAM minimum. It instead documents memory pools such as shared_buffers and per-query work_mem. A dedicated server with at least 1 GB RAM can start shared_buffers around 25% of system RAM, then tune from workload evidence.
Is 2 GB RAM the official PostgreSQL minimum?
No. The current ZimaOS package reserves 2 GB, but that is package-level sizing. PostgreSQL upstream does not define 2 GB as a universal minimum.
Can I use PostgreSQL 6.4's disk requirements today?
No. The supplied PostgreSQL 6.4 page is historical documentation from a very old release and lists tens-of-megabytes source/install/database sizes. Those figures are valuable only as historical context and are irrelevant to modern database capacity planning.
Why does Radiant Logic require at least 8 GB RAM?
That page sizes PostgreSQL for Radiant Logic Identity Analytics workloads, including many identities, permissions and simultaneous connections. Its 8-GB minimum and 16–32-GB recommendation are product-specific deployment guidance, not PostgreSQL upstream requirements.
Why does Genetec say 2 vCPU/8 GB minimum and 4 vCPU/16 GB recommended?
Those numbers are for the Genetec Data Exporter solution's PostgreSQL backend. They depend on that plugin's access-control data and are not a general PostgreSQL minimum.
What does TigerData add to PostgreSQL sizing?
TigerData's operations/performance material reinforces that PostgreSQL sizing is workload-driven: CPU, memory and disk I/O should be monitored and tuned against the database's query and operational behavior. It does not replace current PostgreSQL upstream documentation with one universal minimum.
Why can work_mem cause unexpected RAM usage?
work_mem applies to each sort/hash operation, not once per server or even once per session. A complex query can use several operations, many sessions can run concurrently, and parallel workers can multiply the memory/CPU footprint.
Can ZimaBoard 2 832 run PostgreSQL?
Yes for small personal and home-server application databases. Use SSD-backed data storage, conservative memory settings and connection pooling when needed. Move to 16 GB or stronger storage/CPU only when the measured workload requires it.
What sources and further reading informed this PostgreSQL hardware guide?
The supplied PostgreSQL 6.4 installation page is genuine upstream documentation but is decades old; its roughly 30-MB source, 5-MB install and 1-MB empty-database figures are intentionally classified as historical and not used for current sizing. Radiant Logic requires 8 GB and recommends 16–32 GB for its Identity Analytics PostgreSQL deployment, with fast disks and a many-core example; those figures belong to that product. TigerData's database-operations/performance guidance discusses CPU, memory and disk I/O as workload-dependent PostgreSQL tuning dimensions rather than a universal minimum. Genetec specifies PostgreSQL 16 with 2 vCPU/8 GB as minimum and PostgreSQL 17 with 4 vCPU/16 GB recommended for its Data Exporter solution; again, these are application-specific requirements. Current PostgreSQL 18 resource documentation and the current ZimaOS PostgreSQL 17.4 manifest were separately checked and used as the authority for modern memory behavior and package sizing.
