PostgreSQL локально для разработчика: установка, настройка, память

Прямой ответ

Для локальной разработки PostgreSQL проще всего запустить в Docker — одна команда, чистое удаление, версия совпадает с продом:

docker run -d --name pg-dev -e POSTGRES_PASSWORD=devpass \
  -p 5432:5432 -v pgdata:/var/lib/postgresql/data \
  --memory 1g postgres:16

Нативная установка (apt/Homebrew/установщик EDB для Windows) оправдана, если база нужна постоянно и без Docker-оверхеда. Ресурсы скромные: холостой PostgreSQL занимает 30–50 МБ, а на настройках по умолчанию dev-база на несколько ГБ работает быстро без всякого тюнинга. Осмысленная локальная настройка сводится к трём параметрам: shared_buffers (256 МБ достаточно), work_mem (8–16 МБ), effective_cache_size (половина выделенной базе памяти) — всё остальное тюнингуют уже на сервере.

Docker против нативной установки

Docker — стандарт для проектной работы: версия БД фиксируется в compose-файле (как в статье про локальный Compose-стек), несколько проектов держат разные версии без конфликтов, удаление — docker rm -f pg-dev && docker volume rm pgdata. На Windows/macOS данные обязательно в именованном volume, не в bind mount: файловая трансляция NTFS замедляет БД в разы.

Нативная установка — когда база живёт «всегда»: нет зависимости от Docker-движка (экономия 0,5–1,5 ГБ), служба стартует с системой. На Windows ставьте официальный пакет PostgreSQL (EDB) с pgAdmin; в Ubuntu — apt install postgresql (в LTS может быть не самая свежая ветка — для актуальной добавьте репозиторий PGDG). Минус: параллельные версии и чистое удаление требуют аккуратности.

Практическое правило: учитесь и держите «главную» базу нативно, проектные базы — в контейнерах.

Минимальная настройка: что действительно важно

Файл postgresql.conf (в Docker — через команды или монтируемый конфиг). Для ноутбука:

shared_buffers = 256MB        # кэш страниц; локально больше не нужно
work_mem = 16MB               # на операцию sort/hash; осторожно при десятках соединений
effective_cache_size = 2GB    # подсказка планировщику, не реальное выделение
max_connections = 30          # локально достаточно; каждое соединение ест память

Почему так: work_mem умножается на число одновременных операций — 100 МБ «для скорости» при активном приложении превращаются в гигабайты и OOM. max_connections по умолчанию (100) локально избыточен: пул приложения обычно 5–20 соединений. Автонастройщик pgtune даёт те же рекомендации формально — для dev-машины его выводы можно смело округлять вниз.

Отдельный локальный параметр — fsync. Отключать его «для скорости тестов» — распространённая практика, но только для одноразовых прогонов: при любом сбое питания база может повредиться. Для постоянной dev-базы fsync остаётся включённым.

Подключение и базовая гигиена

psql -h localhost -U postgres          # CLI всегда доступен: \l, \dt, \x, \timing
createdb myapp_dev
pg_dump -Fc myapp_dev > myapp_dev.dump # бинарный дамп: сжатие + выборочное восстановление

Привычки, которые сэкономят часы:

Дамп перед экспериментами с миграциями: pg_dump -Fc занимает секунды на dev-объёмах, восстановление pg_restore -d myapp_dev — тоже.
Отдельные базы на проект (myapp_dev, myapp_test), а не одна «общая» с десятками схем.
\timing в psql включённым всегда — привычка видеть реальную длительность запросов вместо ощущений.
Секреты подключения — в .env приложения, не в коде; правила — в статье про секреты и .env.

Память и диск: сколько нужно базе на ноутбуке

Считается просто: shared_buffers (256 МБ) + соединения × ~10 МБ + кэш ОС. Для локальной разработки резервируйте базе 0,5–1 ГБ в лимитах Docker/системы — этого хватает для баз в десятки ГБ, потому что PostgreSQL работает с диском и кэширует только горячее. Диск — NVMe: журнал WAL пишет постоянно, и на медленном диске транзакции деградируют первыми. Свободное место держите ≥20%: VACUUM и WAL-сегменты требуют запаса. Если база нужна аналитику для больших витрин — требования и расчёт ОЗУ описаны в статье про Power BI/SQL/Pandas.

Когда локального PostgreSQL уже мало

Признаки: рабочая копия прода занимает десятки ГБ, запросы упираются в диск ноутбука, обновление тестовой копии занимает часы. Решение не «тюнинговать ноутбук», а вынести тяжёлую базу на сервер, оставив локальную копию урезанной (срез данных, синтетика) — разработка при этом не замедляется. А для прототипов, где БД не нужна между запусками, рассмотрите SQLite (нулевое администрирование) или testcontainers в тестах — одноразовая БД на каждый прогон.

FAQ

Какую версию PostgreSQL ставить локально? Ту же мажорную, что в проде (обычно 16 или 17). Разница мажорных версий — в поведении планировщика и функциях; локальные тесты на другой версии иногда дают ложный комфорт.

Почему база в Docker тормозит на Windows? Данные лежат в bind mount на NTFS. Перенесите в именованный volume — ускорение в разы; механика описана в статье про WSL2 и Docker.

Нужен ли pgAdmin или хватит psql? Для учебных задач psql + DBeaver/DataGrip покрывают всё; pgAdmin удобен новичку как GUI «из коробки». Тяжёлые GUI-клиенты держат 300–500 МБ — на слабом ноутбуке CLI легче.

Как полностью удалить PostgreSQL в Docker вместе с данными? docker rm -f pg-dev && docker volume rm pgdata. Нативную установку удаляйте штатным деинсталлятором, каталог данных (PGDATA) — вручную после бэкапа.

Локальный мониторинг: видеть, что делает база

Три встроенных представления закрывают 90% локальной диагностики, и знать их полезнее, чем любой внешний дашборд. pg_stat_activity показывает живые соединения и текущие запросы — зависший запрос виден сразу вместе со своим state и длительностью (now() - query_start). pg_stat_statements (включается в shared_preload_libraries) агрегирует статистику по всем запросам: суммарное время, число вызовов, среднее — первый шаг к поиску «кто тормозит». EXPLAIN (ANALYZE, BUFFERS) для конкретного запроса показывает фактический план с реальным временем узлов и попаданиями в кэш — именно его стоит выработать привычку смотреть до добавления индексов «на глаз».

Для GUI-обзора локально достаточно pgAdmin или DBeaver; отдельный Prometheus-стек для dev-базы избыточен. Полезная привычка для аналитических задач: после тяжёлого запроса смотреть не только время, но и Buffers: shared read — большое число чтений с диска говорит, что рабочая выборка не помещается в кэш, и решение здесь — индекс или ограничение объёма, а не «больше памяти».

Как быстро сравнить схемы dev- и прод-базы? Штатно — pg_dump --schema-only обеих баз и diff вывода; для регулярной работы удобнее migra или pgquarrel. Расхождение схем — типичная причина «локально работает, в проде нет», поэтому сравнение стоит включать в чек-лист релиза.

Источники: документация PostgreSQL (runtime config, psql), официальный Docker-образ postgres (ссылки в шапке).

PostgreSQL на ноутбуке разработчика: быстрая установка и настройки, которые имеют смысл локально