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

MAATRIX

NocoDB превращает обычную MySQL или PostgreSQL в интерфейс уровня Airtable — с таблицами, представлениями, формулами и API, но без подписки и без чужого сервера. Вопрос «сколько RAM нужно для NocoDB» упирается не в объём данных, а в архитектуру: сама база живёт отдельно, а Node-процесс NocoDB — это тонкий слой API и рендеринга поверх неё. Разберём, из чего складывается память, где она реально утекает и какой конфиг взять, чтобы не платить за гигабайты, которые не нужны.

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

Главное отличие NocoDB от типичных self-hosted инструментов: она не хранит данные таблиц в памяти процесса. Записи лежат в MySQL/PostgreSQL/SQLite, NocoDB запрашивает их постранично через SQL. Поэтому память растёт не от размера базы, а от числа одновременных запросов, тяжёлых операций (импорт CSV, генерация превью вложений) и того, что стоит рядом.

Из таблицы видно главное: сам процесс NocoDB — не то, что съедает память в продакшене. Она уходит на СУБД рядом, на всплески при импорте/экспорте и на число одновременных пользователей интерфейса.

Из чего складывается память NocoDB

NocoDB — приложение на Node.js: бэкенд ходит в базу через Knex.js (SQL-билдер, а не ORM с полной загрузкой объектов в память), фронтенд — собранный Vue-интерфейс, который сервер просто отдаёт статикой. Официальный Docker-образ nocodb/nocodb — это один контейнер с бэкендом и встроенной раздачей фронтенда, без отдельного nginx.

Из чего набирается расход:

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

Метаданные: SQLite по умолчанию или отдельная PostgreSQL

Если не задать переменную NC_DB, NocoDB создаёт свою служебную SQLite-базу (список проектов, таблиц, пользователей, токенов) в каталоге, заданном NC_TOOL_DIR. Это удобно для быстрого старта, но у SQLite есть архитектурное ограничение: она блокирует файл на запись для одного писателя за раз. Под одного пользователя это незаметно. Под команду, где несколько человек одновременно правят структуру таблиц или система параллельно обрабатывает вебхуки и API-запросы на запись метаданных, начинаются задержки и иногда SQLITE_BUSY.

Для рабочего инстанса переменную NC_DB стоит указать сразу на внешнюю PostgreSQL:

NC_DB=pg://db_host:5432?u=nocodb&p=secret&d=nocodb_meta

Важно различать две вещи, которые легко перепутать:

• метаданные NocoDB (список баз, вью, пользователей, ACL) — то, что описывает переменная NC_DB;
• данные ваших таблиц — они могут лежать в совсем другой базе, которую вы подключаете отдельно через интерфейс как источник (Data Source), в том числе несколько источников на один инстанс NocoDB.

Держать обе базы на одном PostgreSQL-сервере, но в разных схемах или базах данных — рабочий и распространённый вариант: экономит память по сравнению с двумя отдельными СУБД и упрощает бэкапы. Установка самой PostgreSQL под это описана в пошаговой инструкции по PostgreSQL на VPS, там же — базовая настройка postgresql.conf под небольшой сервер.

Docker Compose и переменные, которые держат память под контролем

Базовый рабочий конфиг с лимитом памяти и внешней PostgreSQL под метаданные:

services:
  nocodb:
    image: nocodb/nocodb:latest
    restart: unless-stopped
    mem_limit: 2g
    environment:
      - NC_DB=pg://postgres:5432?u=nocodb&p=${NC_DB_PASSWORD}&d=nocodb_meta
      - NC_TOOL_DIR=/usr/app/data
      - NC_DISABLE_TELE=true
      - NC_PUBLIC_URL=https://nocodb.example.com
    volumes:
      - nocodb-data:/usr/app/data
    ports:
      - "8080:8080"
    depends_on:
      - postgres

  postgres:
    image: postgres:16
    restart: unless-stopped
    mem_limit: 1g
    environment:
      - POSTGRES_USER=nocodb
      - POSTGRES_PASSWORD=${NC_DB_PASSWORD}
      - POSTGRES_DB=nocodb_meta
    volumes:
      - pg-data:/var/lib/postgresql/data

volumes:
  nocodb-data:
  pg-data:

Несколько нюансов, о которые реально спотыкаются:

• NC_TOOL_DIR (том /usr/app/data) нужно монтировать всегда, даже если метаданные вынесены на PostgreSQL — туда пишутся локальные вложения (если не настроено S3-совместимое хранилище), временные файлы импорта и JWT-секрет. Без volume при пересоздании контейнера теряются загруженные файлы, а иногда и токены авторизации.
• Для локальных вложений задайте лимит явно: NC_MAX_ATTACHMENT_SIZE защищает от загрузки файла, который займёт всю доступную память при попытке сгенерировать превью.
• mem_limit на контейнер стоит ставить сразу — без него один тяжёлый импорт или пачка одновременных загрузок изображений может выесть память соседних контейнеров на том же хосте. Общий подход к лимитам разобран в статье про лимиты CPU и памяти в Docker.
• Если подключаете внешние источники данных по MySQL, а не только PostgreSQL, при частых ошибках подключения — типичная причина не в NocoDB, а в лимитах самой СУБД, например too many connections в MySQL при большом числе открытых вкладок и параллельных grid-запросов.

Redis-кэш: когда он реально нужен

NocoDB умеет кэшировать метаданные и часть SQL-результатов через Redis (NC_REDIS_URL). На одном инстансе с несколькими пользователями выигрыш от Redis скромный — основной кэш и так живёт в памяти процесса. Redis становится не опцией, а необходимостью в двух случаях:

1. Горизонтальное масштабирование. Как только NocoDB запущена в двух и более экземплярах за балансировщиком (для отказоустойчивости или под нагрузку), им нужен общий кэш метаданных — иначе один инстанс не увидит изменение структуры таблицы, сделанное через другой, до истечения TTL или рестарта.
2. Частые пересоздания структуры. Если через API или UI постоянно добавляются/удаляются колонки, вью, автоматизации — без общего кэша каждый инстанс отдельно бьёт запросами в базу метаданных при каждом обращении.

NC_REDIS_URL=redis://redis:6379/0

Сам Redis под такую нагрузку — лёгкий процесс, обычно укладывается в первые десятки мегабайт резидентной памяти на небольшом инстансе; закладывайте ему отдельный mem_limit, чтобы не делить кэш-память с NocoDB на одном лимите контейнера.

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

Честный минимум для рабочего использования — 2 vCPU, 4 ГБ RAM, 40 ГБ NVMe, с NocoDB и PostgreSQL для метаданных на одном сервере. Двух гигабайт хватит для теста и знакомства с интерфейсом, но команда из нескольких человек с параллельными вью и вложениями начнёт замечать задержки уже на первой неделе — в основном из-за конкуренции NocoDB и PostgreSQL за одну и ту же память, а не из-за самого объёма данных.

Если NocoDB смотрит на реальную рабочую базу — CRM, каталог, учётную систему, — берите 4 vCPU, 8 ГБ RAM, 80 ГБ NVMe и, желательно, разносите NocoDB и «боевую» PostgreSQL по разным серверам или как минимум по разным контейнерам с отдельными лимитами. Здесь память в первую очередь нужна не NocoDB, а самой СУБД под кэш страниц — общий ориентир по серверам под базы данных разобран в статье «Лучший VPS для базы данных».

Локация — на ваш выбор без технических ограничений. NocoDB не тянет внешние API так интенсивно, как автоматизации вроде n8n (сравнение по памяти — в статье «Сколько RAM нужно для n8n»), поэтому локацию выбирайте по тому, где физически сидит команда и где будет храниться база: для персональных данных сотрудников или клиентов из РФ логичнее российская площадка под 152-ФЗ, для международной команды — Лондон или США с более низкой задержкой до остального мира.

Оплата — картами российских банков, по СБП, криптовалютой или токеном MAAT; для развёртывания через Docker Compose иностранная карта не требуется. Готовый рецепт запуска на чистом сервере — пошаговая установка Docker Compose для продакшена на Ubuntu 24.04.

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