PostgreSQL 18, ClickHouse 26.8 и Qdrant 1.19 можно поднять на одной машине одним compose-файлом — без managed-сервисов и ежемесячного счёта за простаивающие инстансы. Такой локальный стек БД закрывает сразу три типовые задачи AI-проектов: транзакционные данные, аналитические запросы и поиск по эмбеддингам.
О практической сборке сообщает Habr / Новости. Автор описал конфигурацию для WSL: данные лежат в файловой системе Linux, а контейнеры запускаются через Docker Compose. Цель не в том, чтобы заменить корпоративный кластер, а в том, чтобы за вечер получить рабочий полигон для пет-проекта, внутреннего прототипа или локального RAG-приложения.
Роли сервисов здесь разделены без магии. PostgreSQL хранит обычные реляционные сущности: пользователей, историю диалогов, настройки и статистику. ClickHouse берёт на себя тяжёлые выборки по большим таблицам — например, события, логи или агрегированную продуктовую аналитику. Qdrant отвечает за векторы: в него можно складывать эмбеддинги документов и затем искать фрагменты по смыслу, а не по точному совпадению слов.
Эта схема всё чаще появляется в AI-разработке. Одной SQL-базы хватает, пока приложение живёт на CRUD-операциях. Но после подключения LLM обычно возникают два новых контура: нужно считать события и метрики, а также искать релевантный контекст для модели. Тащить для этого три облачных сервиса в ранний прототип — дорого и организационно скучно: аккаунты, ключи, лимиты, биллинг, сетевые правила. Локальный запуск снимает эту часть рутины, хотя не отменяет резервные копии и контроль доступа, если эксперимент вдруг становится продуктом.
Самая полезная часть инструкции — не команды запуска, а список ошибок, которые проявляются уже после «успешного» старта контейнеров. Для PostgreSQL автор предлагает healthcheck через pg_isready и параметр restart: unless-stopped. Первый нужен, чтобы зависимые сервисы ждали реальной готовности базы, а не просто запущенного процесса. Второй важен потому, что restart_policy относится к Swarm и в обычном Compose не решает задачу автоматического перезапуска.
Отдельная ловушка связана с публикацией портов. Запись должна явно связывать порт хоста и порт контейнера — например, 5433:5432. Если оставить только значение из переменной окружения без двоеточия, Compose не получит корректного правила проброса в ожидаемом виде. У ClickHouse портов два: 8123 для HTTP-интерфейса, веб-консоли и запросов через curl, а 9000 — для нативного протокола и ряда клиентских библиотек. Открыть только 8123 означает получить доступный браузерный интерфейс и затем удивляться, почему не подключается клиент.
Для ClickHouse автор также задаёт лимит открытых файлов nofile в 262144. Это не декоративная настройка: колоночная база активно работает с файлами, а дефолтный лимит контейнера может закончиться на заметной нагрузке ошибкой Too many open files. Ещё один совет — не подменять основной config.xml одиночным bind mount. Если файла на хосте нет, Docker способен создать директорию с таким именем, после чего сервер не стартует. Безопаснее добавлять точечные настройки в config.d и users.d, сохраняя конфигурацию образа.
Qdrant в этой тройке требует не меньше внимания, чем PostgreSQL. Его REST API и панель работают на 6333, а gRPC — на 6334. По данным автора, официальный Python-клиент использует gRPC по умолчанию, поэтому открытый только REST-порт создаёт неприятную ситуацию: дашборд доступен, но код получает неочевидную ошибку соединения. В настройках безопасности тоже нет места догадкам: переменные с именами вроде ADMIN_USER и ADMIN_PASSWORD не включают защиту Qdrant. Для API-ключа нужен параметр QDRANT__SERVICE__API_KEY, а клиент должен отправлять ключ в заголовке api-key.
В WSL критичным становится и место хранения данных. Автор рекомендует держать рабочие тома внутри Linux-файловой системы, а не монтировать каталоги из /mnt/c или других дисков Windows. Причина — не только скорость: доступ через 9P способен заметно замедлить ввод-вывод, а для баз данных это риск получить странные сбои и проблемы с записью. Windows-диски разумнее оставить для статических файлов, экспортов и резервных копий, но не для живых каталогов PostgreSQL, ClickHouse и Qdrant.
Такой локальный стек БД особенно полезен разработчикам, которые проверяют гипотезу до выхода в облако: можно отладить схему данных, RAG-пайплайн и аналитические запросы на своём компьютере, не подгоняя архитектуру под тарифы провайдера. Следующий вопрос начинается, когда прототипом начинают пользоваться другие люди: тогда к трём контейнерам быстро добавляются бэкапы, мониторинг, миграции, разграничение доступа и решение о том, что всё-таки пора вынести из ноутбука.
