Baserow 하드웨어 요구 사항: RAM, CPU, 스토리지 및 PostgreSQL, Redis, 워커

배포 환경에 맞는 용량 기준과 실용적인 ZimaOS 가이드를 참고해 Baserow의 RAM, CPU, PostgreSQL, Redis, 백그라운드 작업자 및 업로드 파일을 계획하세요.

Baserow 하드웨어 요구 사항: RAM, CPU, 스토리지 및 PostgreSQL, Redis, 워커

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.

  1. 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.

  2. 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.

  3. 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.

  4. 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.

Review Baserow official requirements

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.

RequirementOfficial minimumWhat this supports
Whole-host RAMNo universal numerical minimum in reviewed current Docker guideOfficial deployment-specific examples must retain their service/container scope.
Whole-host CPUNo universal numerical core minimum in that guideAPI concurrency, formulas and background processes determine practical demand.
AWS service reference2 vCPU / 4 GB RAM recommended for several individual service containersThis is an official deployment reference, not a combined-host minimum.
Database / cachePostgreSQL 14+ and Redis 6.2.7+ in current supported-runtime docsThe all-in-one image includes both by default; external services need their own resources.
Official imagebaserow/baserow:2.4.1 in reviewed Docker guideStandalone backend/frontend images support other topologies; select amd64 on Zima.
Docker runtime19.03 minimum; current Docker recommendedSource Python/Node build/runtime versions are packaged by the prebuilt container.
Persistence / ports/baserow/data; example web ports 80/443Set 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

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.

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 ↗

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.
CPU
Intel N150, 4 cores, up to 3.6 GHz
Memory
16 GB LPDDR5
Storage
64 GB eMMC; add SATA/PCIe SSD storage for persistent application data
Network
Dual 2.5GbE
Acceleration
No dedicated GPU required for this workload.
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.
CPU
Intel Core i5-1235U, 10 cores / 12 threads
Memory
16 GB
Storage
256 GB system storage; six HDD bays and SSD expansion
Network
10GbE plus 2.5GbE
Acceleration
No dedicated GPU required for this workload.
Worker counts, database connections and storage behavior can still be the bottleneck. Get Now

What the Press Says

Highlights from trusted reviewers worldwide.

La Razón
“ZimaCube 2: Not just another NAS, tested with 25TB storage, local AI agents, 4K transcoding, and real homelab workflows.”
Read full review
GameRevolution
“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
TechRadar Pro
“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
FOX 8
“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.

ZimaBlade single-board server
★★★★★

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.

ZimaCube Pro personal cloud
★★★★★

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.

ZimaBlade single-board server
★★★★★

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.

ZimaBoard 2 single-board 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.

  1. Baserow official setup / requirements
  2. Baserow configuration / deployment
  3. Baserow AWS service-sizing references
  4. ZimaBoard 2 specifications
  5. Baserow image source: public project or official store material