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

MAATRIX

SeaTable — self-hosted гибрид таблицы и базы данных, прямая альтернатива Airtable: вьюхи, формулы, связи между таблицами, автоматизации, галерея и канбан поверх обычных строк и столбцов. В отличие от лёгких CRUD-конструкторов вроде NocoDB или Baserow, SeaTable устроен иначе на уровне архитектуры: открытая база не просто читается из СУБД постранично, а целиком загружается в оперативную память процесса, который её обслуживает. Это меняет весь расчёт ресурсов — и именно поэтому вопрос «сколько RAM нужно для SeaTable» не сводится к одной цифре из документации. Разберём, откуда берётся расход памяти, что говорит официальный минимум и как выбрать сервер под реальную нагрузку, а не про запас.

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

Официальный минимум от разработчиков — 4 vCPU и 8 ГБ RAM на сервер с Linux (Debian или Ubuntu), из которых часть уходит под саму ОС и Docker, а не под SeaTable. По их же данным этого хватает «для большинства сценариев с числом пользователей примерно до 100» — при условии, что базы не разрастаются до огромных объёмов и не открыты десятками одновременно. Дальше рост скорее упирается в память, чем в процессор: разработчики прямо отмечают, что после ~8 vCPU и 32 ГБ RAM прирост производительности становится незначительным, а вот RAM нужно добавлять по мере роста баз и числа пользователей.

Для собственного планирования удобнее ориентироваться на сценарии:

Ключевой вывод: 8 ГБ — это не запас с котлом, а честный официальный порог входа. Ниже него SeaTable можно запустить и погонять в одиночку, но это уже эксплуатация не по рекомендациям производителя.

Почему SeaTable держит базы в памяти целиком

Здесь SeaTable принципиально отличается от инструментов вроде NocoDB, которые вычитывают строки из PostgreSQL или MySQL постранично по каждому запросу. У SeaTable своя модель: когда пользователь открывает базу («dtable» на их терминологии), компонент dtable-server запрашивает JSON-представление этой базы у файлового хранилища и загружает его целиком в память процесса. Дальше все операции — правки ячеек, пересчёт формул, фильтрация, real-time совместное редактирование через WebSocket — работают с этой копией в памяти, а на диск данные периодически сохраняются в фоне.

Отсюда практическое следствие: память под SeaTable растёт не столько от числа пользователей интерфейса, сколько от количества и размера одновременно открытых баз. Пять человек в одной небольшой базе дешевле по памяти, чем один человек с десятью открытыми крупными базами в разных вкладках — каждая занимает своё место в памяти dtable-server, пока открыта. Точных цифр «сколько мегабайт весит база на десять тысяч строк» разработчики не публикуют — зависит от числа столбцов, формул и связей, ориентируйтесь на docker stats на своих реальных базах, а не на чужие бенчмарки.

За хранение самих данных на диске и раздачу их dtable-server отвечает отдельный слой файлового хранилища (в терминологии SeaTable — dtable-storage-server), унаследованный от Seafile — той же команды, что делает одноимённый self-hosted файлообменник.

Из чего состоит SeaTable-инстанс

Стандартная установка через официальный Docker-рецепт поднимает четыре контейнера:

Обратите внимание: это архитектурно ближе к «одно тяжёлое приложение плюс лёгкая обвязка», чем к классической связке «веб-сервер плюс СУБД», как у NocoDB — подробное сравнение архитектур приведено в статье «Сколько RAM нужно для NocoDB». Если вы уже держите MySQL или MariaDB под другие сервисы на том же сервере, базовая установка описана в инструкции по MariaDB на VPS.

Официальный docker-compose и где выставлять лимиты

Разработчики распространяют готовый релиз (seatable-compose.tar.gz из GitHub-репозитория seatable/seatable-release) с docker-compose файлом и отдельным .env для настроек. Упрощённая структура, на которую стоит ориентироваться при выставлении лимитов памяти на контейнеры:

services:
  seatable:
    image: seatable/seatable-community:latest
    restart: unless-stopped
    mem_limit: 6g
    env_file: .env
    volumes:
      - seatable-data:/shared
    depends_on:
      - db
      - memcached
      - redis
    ports:
      - "80:80"
      - "443:443"

  db:
    image: mariadb:10.11
    restart: unless-stopped
    mem_limit: 1.5g
    environment:
      - MYSQL_ROOT_PASSWORD=${DB_ROOT_PASSWD}
    volumes:
      - db-data:/var/lib/mysql

  memcached:
    image: memcached:1.6
    restart: unless-stopped
    mem_limit: 256m

  redis:
    image: redis:7
    restart: unless-stopped
    mem_limit: 256m

volumes:
  seatable-data:
  db-data:

В .env задаются как минимум SEATABLE_SERVER_HOSTNAME, SEATABLE_SERVER_PROTOCOL, DB_ROOT_PASSWD, SEATABLE_ADMIN_EMAIL, SEATABLE_ADMIN_PASSWORD и TIME_ZONE. Перед разворачиванием сверьтесь с актуальной версией файла в официальном релизе — набор переменных и образов меняется между релизами SeaTable, и переписывать его вручную по памяти рискованно.

Практический момент: на 8 ГБ сервере mem_limit для контейнера seatable стоит ставить с явным запасом под ОС и Docker — если отдать под него все 8 ГБ без остатка, при пиковой нагрузке ядро может начать убивать процессы по OOM раньше, чем сработает внутренняя защита самого SeaTable. Общий подход к выставлению лимитов на контейнеры и что происходит при их превышении разобран в статье «Лимиты CPU и памяти в Docker».

Что резко увеличивает потребление RAM

Несколько факторов толкают потребление памяти заметно выше базового сценария:

• Много одновременно открытых крупных баз. Каждая открытая база держится в памяти dtable-server, пока с ней работают. Команда из десятков человек, открывающих разные большие базы параллельно, требует памяти пропорционально сумме этих баз, а не среднему размеру одной.
• Формулы и связи между таблицами. Пересчёт формул (особенно ссылающихся на другие таблицы через link-колонки) выполняется в памяти при каждом релевантном изменении — чем сложнее граф связей, тем заметнее расход на пересчёт.
• Вложения и превью. Загрузка файлов сама по себе не держится в памяти постоянно (хранение — на диске через файловый слой), но генерация превью изображений и документов при загрузке даёт кратковременные всплески.
• Collabora Online или OnlyOffice рядом. Если подключаете просмотр и редактирование офисных файлов прямо в SeaTable, эти сервисы — отдельные тяжёлые Java/C++-процессы со своими требованиями к памяти, и их нужно закладывать сверх бюджета самого SeaTable, а не внутри него.
• Автоматизации и интеграции (в том числе через n8n). Массовые автоматизации, срабатывающие на bulk-изменения, создают очередь задач через Redis и нагрузку на dtable-server одновременно — на больших базах это заметно ощутимее, чем на NocoDB с её более пассивными вебхуками.
• Рост числа пользователей выше ~100. Именно этот порог разработчики называют границей, после которой стоит думать не про добавление RAM на одном сервере, а про вынос компонентов (dtable-server, dtable-db) на отдельные ноды в кластерной конфигурации.

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

Для знакомства с SeaTable — своей базы контактов, учёта проектов, каталога — минимум 2 vCPU, 4 ГБ RAM, 20–40 ГБ NVMe запустится и будет работать, но это ниже официальной рекомендации, и на первой же более объёмной базе стоит быть готовым мигрировать выше.

Для конфигурации, которая соответствует официальному минимуму и рассчитана на команду до сотни пользователей с базами среднего размера, берите 4 vCPU, 8 ГБ RAM, 40–80 ГБ NVMe — это порог, ниже которого разработчики прямо не гарантируют стабильную работу. Планируете подключать Collabora или OnlyOffice для просмотра файлов — закладывайте их как отдельный сервер или контейнер с собственным лимитом памяти, а не делите бюджет с SeaTable.

Для production с крупными базами, автоматизациями и десятками параллельных пользователей разумная точка старта — 4–8 vCPU, 16 ГБ RAM, 80–160 ГБ NVMe, с переходом на кластер (отдельные ноды под dtable-server и dtable-db), если упрётесь в потолок по памяти раньше, чем по CPU. Общие принципы подбора сервера под тяжёлые базы данных — в статье «Лучший VPS для базы данных в России»; если рядом крутится MySQL под другие нужды и ловите ошибки подключения при пике, причина разобрана в статье про too many connections в MySQL.

Локация особой роли не играет технически: SeaTable не тянет внешние API так интенсивно, как ИИ-инструменты, поэтому выбирайте по тому, где физически сидит команда и где по регуляторным соображениям должны храниться данные — для персональных данных сотрудников или клиентов из РФ логичнее российская площадка, для международной команды — Лондон или США с меньшей задержкой до остального мира.

Оплата — картами российских банков, по СБП, криптовалютой или токеном MAAT; иностранная карта для аренды сервера и разворачивания SeaTable через Docker не нужна.

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