Сколько RAM нужно для Baserow

MAATRIX

Baserow подкупает обещанием «Airtable, только свой»: поднял контейнер — и вот уже таблицы, вьюхи, формы и API. На практике официальный all-in-one образ на VPS с 1 ГБ RAM либо не стартует, либо падает после первого же импорта CSV на пару тысяч строк. Разберём, из каких процессов складывается память Baserow, чем all-in-one образ отличается от production-конфигурации из отдельных сервисов и сколько реально закладывать под вашу команду.

Короткий ответ: сколько RAM нужно для Baserow

Аппетит Baserow задают три вещи: сколько человек работает с таблицами одновременно, насколько крупные у вас импорты/снапшоты и стоит ли рядом на той же машине что-то ещё.

Ключевое: сам Baserow в покое, без открытых вкладок и фоновых задач, — это несколько сотен мегабайт. Всё, что выше четырёх гигабайт, — это не рост числа таблиц, а объём данных, которые Django и Celery держат в памяти во время конкретной операции: импорта, дублирования базы, генерации отчёта.

Из каких процессов складывается память

Baserow — это не одно приложение, а связка из нескольких процессов, даже когда всё упаковано в один Docker-образ. Backend написан на Python (Django REST Framework), фронтенд — на Vue/Nuxt, реального времени добавляют вебсокеты через ASGI-сервер, фоновые задачи разгребает Celery.

docker exec baserow ps aux --sort=-rss | head -15

Типичный набор процессов и что они добавляют к суммарному расходу:

Ничего из этого не работает в изоляции: открытая вкладка с таблицей держит вебсокет-соединение к backend, а любое изменение ячейки одним пользователем должно долететь до всех остальных открытых вкладок через Redis — это плата за совместное редактирование в реальном времени, а не баг.

All-in-one образ против split-конфигурации

Официальный baserow/baserow — это единый образ, который поднимает встроенные PostgreSQL и Redis прямо внутри контейнера вместе с backend, worker и frontend. Удобно для теста за одну команду:

docker run -d --name baserow \
  -v baserow_data:/baserow/data \
  -p 8080:80 -p 8443:443 \
  --restart unless-stopped \
  baserow/baserow:latest

Проблема для продакшена не в потреблении памяти как таковом, а в том, что все процессы делят один cgroup-лимит и один диск. Тяжёлый Celery-импорт и Postgres, которому в этот момент нужно писать WAL, конкурируют за одну и ту же память — и если контейнеру не хватает запаса сверх «спокойного» уровня, первым падает не worker, а весь контейнер целиком, включая базу.

Production-путь — вынести Postgres, Redis, backend, worker, beat и frontend отдельными сервисами в docker-compose.yml с индивидуальными лимитами:

services:
  db:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      POSTGRES_DB: baserow
      POSTGRES_USER: baserow
      POSTGRES_PASSWORD: change_me_strong
    volumes:
      - ./pgdata:/var/lib/postgresql/data
    mem_limit: 2g

  redis:
    image: redis:7-alpine
    restart: unless-stopped
    command: redis-server --maxmemory 256mb --maxmemory-policy allkeys-lru
    mem_limit: 300m

  backend:
    image: baserow/backend:1-latest
    restart: unless-stopped
    depends_on: [db, redis]
    environment:
      DATABASE_HOST: db
      REDIS_HOST: redis
    mem_limit: 1.5g

  celery-worker:
    image: baserow/backend:1-latest
    command: celery -A baserow worker -l INFO -Q celery,export,thumbnails
    depends_on: [db, redis]
    mem_limit: 1.5g

  celery-beat:
    image: baserow/backend:1-latest
    command: celery -A baserow beat -l INFO
    mem_limit: 300m

  web-frontend:
    image: baserow/web-frontend:1-latest
    restart: unless-stopped
    depends_on: [backend]
    mem_limit: 600m

Разница на восьмигигабайтном сервере ощутимая: разнесённые лимиты не дают одному тяжёлому импорту утащить за собой Postgres, а падает и перезапускается изолированно тот сервис, который реально упёрся в потолок. Для установки с нуля через reverse-proxy и SSL есть отдельный разбор — как поставить NocoDB на VPS описывает похожую схему для соседнего инструмента того же класса.

Что раздувает память сверх базового уровня

Три операции регулярно превращают спокойный сервер в кандидата на OOM:

• Импорт CSV/Excel. Backend создаёт строки пакетами внутри одной транзакции; чем шире таблица и чем больше формул и связей между таблицами, тем больше промежуточных объектов держится в памяти Celery-worker до коммита. Импорт на несколько сотен тысяч строк стоит запускать в окно с запасом свободной памяти, а не на пике рабочего дня.
• Снапшоты и дублирование базы. Функция «Duplicate database» и создание снапшота проходят через backend, который вычитывает структуру и данные исходной базы для копирования. На крупной базе с множеством связей это ощутимый разовый пик — заметно выше повседневной работы с той же базой в интерфейсе.
• Автоматизации и вебхуки. Каждое правило-автоматизация выполняется через Celery и держит воркер занятым до конца цепочки. При активном потоке вебхуков наружу — в Slack, Telegram, внешние API — воркеру нужно место под очередь задач, а не только под саму логику.

Ничего из этого нельзя измерить одной универсальной цифрой «мегабайт на строку» — расход зависит от ширины таблицы и числа связей. Практичнее прогнать самый тяжёлый ожидаемый импорт на стенде с ограниченным mem_limit и посмотреть, укладывается ли он в план по железу, чем искать готовую формулу.

Как поймать OOM и что настроить

Первый шаг при подозрении на нехватку памяти — не гадать, а проверить, кто именно убил процесс:

docker inspect baserow-celery-worker --format '{{.State.OOMKilled}} {{.State.ExitCode}}'
dmesg -T | grep -i "out of memory"

true 137 и строка вида Memory cgroup out of memory: Killed process ... (celery) в dmesg однозначно указывают на упор в лимит контейнера, а не на баг в приложении. Для постоянного наблюдения удобнее снимать метрики раз в 10–30 секунд в течение суток — так виден не мгновенный расход, а пик под ночным или пиковым сценарием:

while true; do docker stats --no-stream --format '{{.Name}}\t{{.MemUsage}}\t{{.CPUPerc}}' | grep baserow; sleep 15; done | tee -a /var/log/baserow-mem.log

Что реально снимает нагрузку без апгрейда тарифа:

• Ограничить конкурентность Celery-воркера флагом --concurrency=2 вместо значения по числу CPU — на слабой машине лучше выполнять импорты по очереди, чем параллельно и с риском OOM.
• Разнести очереди задач: экспорт, превью и обычные CRUD-задачи Celery можно развести по очередям (-Q export, -Q thumbnails, -Q celery) и поднять под тяжёлые операции отдельный воркер с собственным лимитом.
• Настроить shared_buffers в PostgreSQL под реальный объём RAM, а не оставлять дефолт — общие рекомендации в разборе тюнинга PostgreSQL на сервере применимы без изменений.
• Ограничить Redis через maxmemory и allkeys-lru — без потолка кеш будет расти, пока не упрётся в лимит контейнера сам, отобрав память у соседей. Механику cgroup v2 подробнее разбирает материал про лимиты CPU и памяти в Docker.

Честно о границах: ни одна из этих настроек не превратит двухгигабайтный сервер в восьмигигабайтный — они убирают ситуации, когда память тратится впустую, но не отменяют того, что импорт большого файла требует памяти пропорционально его размеру.

Какой сервер взять в MAATRIX под Baserow

Для теста и знакомства с интерфейсом хватает 2 vCPU, 2 ГБ RAM, 20 ГБ NVMe на all-in-one образе — с оговоркой, что это не про повседневную работу команды, а про «посмотреть, подходит ли инструмент».

Для рабочей инсталляции с командой до пары десятков человек честный минимум — 2–4 vCPU, 4–8 ГБ RAM, 40–80 ГБ NVMe на split-конфигурации из docker-compose выше: этого достаточно, чтобы разнести Postgres, Redis, backend, worker и frontend по отдельным лимитам и пережить редкий крупный импорт без падения всей системы. Если у вас есть представление, сколько закладывать по памяти в целом, а не только под Baserow, — общий подход описан в статье сколько оперативной памяти закладывать с запасом.

Организациям с несколькими workspace, активными автоматизациями и снапшотами баз стоит сразу смотреть на 8 vCPU, 16 ГБ RAM, 120+ ГБ NVMe — здесь уже имеет смысл выносить отдельный воркер под тяжёлые задачи (импорт, дублирование) на собственный лимит памяти, чтобы он не мог утащить за собой основной backend.

По локации жёсткой привязки нет: Baserow — это в первую очередь внутренний инструмент команды, а не сервис с активным исходящим API-трафиком, как боты или интеграции. Для команды, которая физически в России, разумный выбор — российская площадка ради минимальной задержки для всех участников; для распределённой команды или если рядом стоят внешние интеграции (Slack, внешние API в автоматизациях) — Лондон или Франкфурт дают стабильный доступ к зарубежным сервисам без прокси.

Оплата — картами российских банков, по СБП, криптовалютой или токеном MAAT, без необходимости в иностранной карте даже для зарубежной площадки. Если данные, которые пойдут в таблицы, персональные и подпадают под 152-ФЗ, — берите российскую локацию сразу, переносить базу между дата-центрами задним числом не самая приятная задача.

Частые вопросы