Inspect worker backlog, query behavior and CPU during representative large-table operations; worker count and database capacity must be balanced.
Large tables or frequent bulk jobs.Configuration matérielle requise pour Baserow : RAM, CPU, stockage et PostgreSQL, Redis et workers
Prévoyez les ressources nécessaires pour Baserow : RAM, CPU, PostgreSQL, Redis, workers en arrière-plan et fichiers téléversés, avec des repères de dimensionnement selon le déploiement et des conseils pratiques pour ZimaOS.
Baserow hardware requirements at a glance
Baserow sizing changes with deployment topology, worker counts, formulas, imports and attachments. The reviewed current Docker guide gives no universal numerical whole-host minimum. Its all-in-one image includes PostgreSQL, Redis, web services and workers; cloud sizing references retain their per-container scope.
- RAM
- No universal numerical whole-host minimum is published in the reviewed current Docker guide. Official AWS guidance recommends 4 GB per several individual service containers, not 4 GB for an entire multi-service host.
- CPU
- No universal numerical whole-host core floor is given in that guide. AWS examples recommend 2 vCPU for several individual services; concurrent API work and background jobs drive actual demand.
- Storage
- Persist /baserow/data for the all-in-one setup and size database, uploaded files and backups. External database/object storage moves that state elsewhere; it does not eliminate its resource cost.
- Database / cache
- PostgreSQL and Redis are included in the all-in-one image unless configured externally. Current supported-runtime docs list PostgreSQL 14+ and Redis 6.2.7+; follow release-matched requirements.
- Workers / runtime
- API and Celery processes consume separate resources. Source-development Docker RAM guidance and per-worker memory observations are not whole-host production minimums.
- Best Zima starting point
- ZimaBoard 2 1664 is a practical starting choice for a consolidated small Baserow stack. An 8 GB host is an option only for a measured modest workload with conservative process counts.
From official requirements to the right setup
Plan the complete Baserow workload before selecting a server.
-
Official requirements
Choose all-in-one or separate services before comparing hardware numbers. The reviewed Docker guide requires Docker 19.03+ but recommends a current Docker release; the image supplies the application runtime.
-
Confirm your needs
Measure active editors, API traffic, formula complexity, import/export volume and background tasks. Increasing workers adds memory and database connections as well as concurrency.
-
Leave room to grow
Persist /baserow/data in the all-in-one setup. Back up external PostgreSQL and user-file storage separately when selected; a workspace export is not a complete instance recovery backup.
-
Run it on ZimaOS
Custom install the official stable image in ZimaOS, set the public URL and map available web ports. Avoid taking host 80/443 from ZimaOS or another proxy; preserve the release-appropriate database layout during upgrades.
Check every playback client
- All-in-one versus separate service topology
- Concurrent editors/API requests
- Gunicorn and Celery worker counts
- Large imports/exports and formula work
- PostgreSQL/Redis versions and connections
- Uploaded files and object-storage policy
- Persistent /baserow/data or external state
- Public URL, web ports and tested backups
Official minimum requirements
Reviewed October 30, 2026 against the linked upstream deployment documentation. Numerical values retain their stated minimum, recommendation or example scope; select release-compatible instructions before installation.
Do not turn AWS per-service recommendations, 512 MB per-worker estimates, or 4 GB development-environment guidance into a universal Baserow host minimum. Account for all processes, SQL/cache services and file storage in the selected deployment.
| Requirement | Official minimum | What this supports |
|---|---|---|
| Whole-host RAM | No universal numerical minimum in reviewed current Docker guide | Official deployment-specific examples must retain their service/container scope. |
| Whole-host CPU | No universal numerical core minimum in that guide | API concurrency, formulas and background processes determine practical demand. |
| AWS service reference | 2 vCPU / 4 GB RAM recommended for several individual service containers | This is an official deployment reference, not a combined-host minimum. |
| Database / cache | PostgreSQL 14+ and Redis 6.2.7+ in current supported-runtime docs | The all-in-one image includes both by default; external services need their own resources. |
| Official image | baserow/baserow:2.4.1 in reviewed Docker guide | Standalone backend/frontend images support other topologies; select amd64 on Zima. |
| Docker runtime | 19.03 minimum; current Docker recommended | Source Python/Node build/runtime versions are packaged by the prebuilt container. |
| Persistence / ports | /baserow/data; example web ports 80/443 | Set the actual public URL and use available host mappings or an existing proxy. |
When to upgrade your hardware
Use observed Baserow workload pressure to decide when an upgrade is warranted.
Imports or formula changes delay collaboration
More processes exhaust RAM or SQL connections
Database and file backups exceed available storage
Check resident memory, swap and connection counts before adding Gunicorn/Celery workers. More workers are not free parallelism.
Concurrent editors and API integrations.Track uploads, SQL data/indexes and complete backup copies; workspace export alone does not preserve all instance state.
Attachment-rich workspaces and long retention.Plan hardware growth with confidence
Address storage, memory, compute and deployment limits separately.
Use fast durable PostgreSQL storage
Prioritize active SQL latency and complete backup recovery before increasing application CPU.
SATA/PCIe SSD for ZimaBoard 2.Add host memory for the complete stack
Choose 16 GB for a modest consolidated stack when processes and services fit the measured budget.
ZimaBoard 2 1664.Separate capacity-heavy uploads
Add storage or a supported object store for file retention while retaining database backups.
Additional SSD or storage-oriented ZimaCube 2 when justified.Scale measured API and job demand
Select stronger compute or separate services when actual workload pressure warrants it.
ZimaCube 2 Pro; keep database/cache sizing aligned.Can it run on ZimaOS?
No specific public official one-click Baserow ZimaOS page was verified. Use Custom Install and choose the intended all-in-one or separate-service topology explicitly.
Custom install Baserow in ZimaOS
Use a stable Baserow image, preserve /baserow/data or external state, set the public URL and remap web ports for the current host. Keep worker/process counts within measured memory and SQL capacity.
Custom install Baserow in the ZimaOS app ↗Use the official Baserow deployment instructions
Keep the selected stable release, persistent paths and companion services aligned with upstream documentation.
Review Baserow official installation ↗Verify release-specific runtime dependencies
Check supported PostgreSQL, Redis and packaged runtime versions rather than copying source-development requirements as server minimums.
Review Baserow deployment details ↗Which Zima hardware fits Baserow?
Start with the lowest reasonable host for the actual workload. Product specifications were checked against the current product pages.
Which workload best matches your Baserow deployment?
Modest all-in-one database workspace
Use durable SSD storage and conservative process counts.
- Workload optionZimaBoard 2 1664
Measured higher concurrency or larger job workloads
Use stronger compute and plan all services together.
- Workload optionZimaCube 2 Pro
These are practical workload recommendations, not official app requirements, compatibility certification, measured capacity limits or performance guarantees. Include all co-hosted services and independent backups.
| Zima hardware | Best for | Example workload | Core configuration | Recommended boundary | Next step |
|---|---|---|---|---|---|
| ZimaBoard 2 1664 | Small consolidated Baserow stack | App services, PostgreSQL, Redis and controlled background workers. |
|
16 GB is an editorial starting choice, not an upstream universal minimum or a row-capacity guarantee. | Get Now |
| ZimaCube 2 Pro | Busier data workflow | More compute for API requests, imports and broader service consolidation. |
|
Worker counts, database connections and storage behavior can still be the bottleneck. | 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
Answers to Baserow RAM, CPU, storage, Docker, database and ZimaOS sizing questions.
What is the official Baserow RAM minimum?
The reviewed current Docker guide does not define a universal whole-host number. Official cloud guides provide topology-specific service references, which must not be presented as complete-server minimums.
How much CPU should I plan?
Use concurrency, formula work and background imports/exports. AWS guidance recommends 2 vCPU for several individual services, while the whole host must cover all services that run there.
Does Baserow require PostgreSQL and Redis?
The standard all-in-one image includes both by default; they can be externalized. Current supported-runtime docs list PostgreSQL 14+ and Redis 6.2.7+, with release-specific tested/recommended versions.
What storage must be persistent?
Persist /baserow/data for the all-in-one setup. If database or uploaded files are external, back those up separately. A workspace export does not replace a full instance recovery plan.
Does Baserow need a GPU?
Ordinary database views, formulas, API requests and background jobs do not require a dedicated GPU. Optional AI/embedding services have separate provider/model resource requirements.
Can ZimaBoard 2 run Baserow?
A 16 GB model is a practical modest-stack starting candidate with SSD-backed state and controlled workers. Validate the actual job/concurrency profile; more RAM does not change the four-core N150 CPU.
Why not keep increasing worker counts?
Each process consumes memory and database/cache connections. Increasing concurrency beyond SQL/I/O capacity can worsen latency or cause memory pressure instead of improving throughput.
When should I choose ZimaCube 2 Pro?
Consider it for demonstrated CPU-heavy jobs or wider consolidation. First check SQL storage, connection limits, formulas and worker configuration so the upgrade addresses the real bottleneck.
What sources informed this Baserow hardware guide?
This guide was reviewed against the linked project deployment documentation on October 30, 2026. Zima device choices are editorial workload guidance, separate from upstream requirements and measured performance.
