PocketBase recommends increasing the open-file descriptor limit when large numbers of connections produce 'Too many open files'. CPU/RAM may still be healthy.
Realtime dashboards, chat, IoT and multi-user apps.Wymagania sprzętowe PocketBase: pamięć RAM, SQLite, funkcja Realtime i pamięć masowa
Poznaj wymagania PocketBase dotyczące pamięci RAM, SQLite, aktualizacji w czasie rzeczywistym, przechowywania plików i kopii zapasowych, a następnie wybierz odpowiedni sprzęt ZimaOS do samodzielnie hostowanego backendu.
PocketBase requirements at a glance
PocketBase does not publish a numerical CPU or RAM minimum. It is a self-contained Go backend with embedded SQLite, realtime subscriptions, auth, file storage and an admin dashboard. The official FAQ even lists 0.25 vCPU / 1 GB RAM free-tier hosting for small PoCs and reports 10,000+ persistent realtime connections on a cheap 2-vCPU / 4-GB VPS, but these are examples and benchmarks rather than guaranteed minimum or capacity limits.
- CPU
- No numerical official minimum. API handlers, hooks, file processing, thumbnails and high concurrency determine real CPU demand.
- RAM
- No numerical official minimum. PocketBase documents GOMEMLIMIT as an optional soft limit for constrained environments or large uploads; 512MiB is shown only as an example.
- Database
- PocketBase uses embedded SQLite in WAL mode and does not plan a pluggable MySQL/PostgreSQL replacement for the normal product architecture.
- Scaling
- PocketBase scales vertically on a single server rather than horizontally as a built-in cluster. The official FAQ positions it for small and midsize applications.
- Storage
- Persist pb_data. It includes the SQLite database and locally stored files; S3-compatible storage is also available for application files/backups.
- Best Zima starting point
- ZimaBoard 2 832 is already a strong PocketBase host. Move up for heavier file/media workloads, more concurrent realtime users, larger logs/backup windows or a broader developer stack.
From official requirements to the right setup
PocketBase sizing starts with the single-server SQLite architecture and the amount of traffic/files it handles.
-
Official requirements
Start with a single persistent PocketBase instance and pb_data volume. The official production guide emphasizes that no external runtime dependency is required.
-
Confirm your needs
Estimate API/realtime concurrency and file workload separately. Thousands of open realtime connections stress file descriptors/network differently from large uploads, thumbnail generation or hooks.
-
Leave room to grow
Plan pb_data and backup growth. Built-in ZIP backups put the application temporarily in read-only mode; PocketBase recommends another strategy when pb_data becomes large, giving 2 GB+ as an example.
-
Run it on ZimaOS
Install PocketBase from ZimaOS, test real API/realtime/upload behavior, tune log retention/rate limits/file descriptors and monitor Go memory before moving to larger hardware.
Check every playback client
- API request rate
- Persistent realtime connections
- SQLite read/write concurrency
- File upload and thumbnail workload
- Local files versus S3-compatible storage
- Log retention
- pb_data size and backup window
- Open-file descriptor limit
Official minimum requirements
PocketBase provides production examples and scaling guidance rather than a fixed CPU/RAM minimum.
Do not publish 1 GB as an official PocketBase minimum. The official FAQ merely points to a 0.25-vCPU/1-GB free VM as a PoC option and separately reports project benchmark experience on 2 vCPU/4 GB.
| Requirement | Official minimum | What this supports |
|---|---|---|
| CPU | No numerical minimum published | Official examples include very small VPS instances for hobby/PoC deployment. |
| RAM | No numerical minimum published | 1 GB is mentioned as a free-tier hosting example, not a requirement. |
| Database | Embedded SQLite in WAL mode | PocketBase's normal architecture is deliberately single-server. |
| Scaling model | Vertical / single server | Official FAQ says PocketBase does not provide built-in horizontal multi-server scaling. |
| Persistent data | pb_data | Official Docker production example requires a persistent volume at /pb/pb_data. |
| Memory control | Optional GOMEMLIMIT, e.g. 512MiB example | A soft Go memory limit for constrained hosts, not an official RAM minimum. |
When to upgrade your hardware
Upgrade PocketBase when realtime/file/SQLite workload or backup growth creates measurable pressure.
Many concurrent realtime connections hit OS/network limits
Large uploads, thumbnails or hooks create memory spikes
pb_data and backup windows grow beyond the simple built-in snapshot path
PocketBase's maintainer notes that occasional RAM spikes can come from file uploads, thumbnail generation, concurrent requests and hooks, and documents GOMEMLIMIT for constrained environments.
Media-heavy applications and custom hook workloads.PocketBase says the built-in ZIP backup can become slow on large pb_data and suggests a different backup method at around multi-GB scale.
Long-lived apps with growing databases and local files.Plan hardware growth with confidence
Scale PocketBase vertically while keeping SQLite and persistent data on responsive storage.
Keep active pb_data on SSD/NVMe
SQLite WAL, indexes, logs and file metadata benefit from low-latency local persistent storage.
Use SATA SSD/NVMe rather than letting a growing backend depend on tiny or full system storage.Use S3-compatible storage for file-heavy applications
PocketBase supports file storage and backups in S3-compatible storage, which can keep large media assets from dominating local server capacity.
Choose local multi-drive storage or S3 according to backup/recovery and access needs.Tune logs and Go memory on constrained systems
Project usage reports show large apparent memory and disk-write changes can relate to request/upload spikes and logging. GOMEMLIMIT can make GC more aggressive.
Tune before assuming every memory graph requires a RAM upgrade.Change architecture when single-server vertical scaling is no longer enough
PocketBase intentionally does not provide built-in horizontal clustering. If the workload needs multi-node failover/sharding, changing backend architecture may be more appropriate than endlessly scaling one host.
Know when the application has outgrown PocketBase's intended single-server model.Can it run on ZimaOS?
PocketBase is currently available in the ZimaOS App Store.
Install PocketBase from the ZimaOS App Store
Use the packaged all-in-one backend and keep pb_data persistent.
Open PocketBase in the ZimaOS App StoreFollow PocketBase's single-server production model
The official production guide covers direct HTTPS or reverse-proxy deployment, pb_data persistence and backups.
Read PocketBase production guidanceTreat resource examples as examples, not minimums
PocketBase's FAQ discusses tiny VPS options and benchmark capacity, but does not declare a universal CPU/RAM floor.
Read PocketBase FAQChoose Zima hardware for PocketBase
PocketBase is lightweight for many applications, but file workloads, realtime connections and the broader app stack can make storage and RAM increasingly important.
Is PocketBase serving a small app, or a larger file/realtime backend plus other services?
Personal/small application backend
ZimaBoard 2 832 provides large headroom over PocketBase's lightweight production examples.
- Normal PocketBase backendZimaBoard 2 832
- More users/hooks/developer servicesZimaBoard 2 1664
File-heavy or larger all-in-one backend server
Move to ZimaCube for storage and stronger whole-server workload capacity.
- Multi-drive PocketBase/file serverZimaCube 2 Standard
- Larger backend and 10GbE storage workflowZimaCube 2 Pro
No fixed requests-per-second, users or realtime-connection guarantee is implied. Schema, SQLite writes, hooks, files, thumbnails, logs, network and client behavior all affect capacity.
| Zima hardware | Best for | Example workload | Core configuration | Recommended boundary | Next step |
|---|---|---|---|---|---|
| ZimaBoard 2 832 | A personal, internal or small SaaS PocketBase backend. | SQLite API/auth/realtime and modest local files. |
|
Single-server SQLite architecture and file workload—not baseline compute—will determine later scaling. | Get Now |
| ZimaBoard 2 1664 | PocketBase plus more hooks, users and developer services. | More concurrent application work and larger shared server headroom. |
|
16 GB is not a PocketBase requirement; it is capacity for the wider backend stack. | Get Now |
| ZimaCube 2 Standard | A file-heavy PocketBase backend with integrated local storage. | SQLite backend plus larger locally stored uploads and backups. |
|
Choose it for storage growth rather than because PocketBase needs a Core i3. | Get Now |
| ZimaCube 2 Pro | A larger all-in-one backend/storage platform. | More application services, local storage and fast LAN workflows. |
|
PocketBase still scales as one server; 10GbE does not convert it into a multi-node database. | 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 1 GB VPS hosting, SQLite limits, realtime connections, RAM growth, files and backups. PocketBase discussions and Reddit are used for real-world scaling questions while official docs define architecture.
How much RAM does PocketBase need?
PocketBase does not publish a RAM minimum. Its official FAQ mentions a 1 GB free-tier VM as a hobby/PoC hosting option, but that is an example rather than a requirement.
Can PocketBase run on 1 GB RAM?
Yes for many small applications. The official FAQ points to 1 GB free-tier hosting, and current community users also run low-cost 1 GB VPS deployments. File uploads, hooks and higher concurrency can require more headroom.
How many realtime connections can PocketBase handle?
PocketBase's official FAQ says it can serve 10,000+ persistent realtime connections in its benchmark/example on a cheap 2-vCPU/4-GB VPS. Treat that as project test evidence, not a universal Zima guarantee.
Why can PocketBase memory usage jump even when the database is small?
The maintainer notes that apparent memory spikes can come from file uploads, thumbnail generation, high concurrent requests and hooks, while Go may not immediately return unused memory to the OS.
Can PocketBase use PostgreSQL or MySQL instead of SQLite?
Not as the normal built-in database. PocketBase deliberately uses embedded SQLite in WAL mode and its FAQ says there are no plans for interchangeable external databases.
Can PocketBase scale horizontally across several servers?
Not as a built-in architecture. PocketBase's official FAQ says scaling is single-server/vertical; applications that truly require clustering or multi-node database failover may need a different backend architecture.
When should I set GOMEMLIMIT?
PocketBase suggests it for memory-constrained deployments or large file uploads. The documented 512MiB value is only an example soft limit and can still be exceeded in some situations.
Can ZimaBoard 2 832 run PocketBase?
Yes. Its Intel N150 and 8 GB RAM provide very large headroom for a normal small/midsize PocketBase deployment; use SSD/SATA storage as pb_data and files grow.
What sources and further reading informed this PocketBase hardware guide?
PocketBase's current FAQ and production guide provide the single-server scaling model, tiny-VPS examples, 10k+ realtime benchmark reference, pb_data persistence, backup behavior, file-descriptor guidance and GOMEMLIMIT. A project production-use discussion was used for memory/log/file workload fan-out, while Reddit was used for low-cost deployment questions. ZimaOS confirms the current app.
