PostgreSQL как мозг управления 16 виллами на Бали

3 апреля 2026 Юрий Солар

Когда у тебя 16 вилл, куча менеджеров и нескончаемый поток гостей — легко потерять контроль. Всё, что не автоматизируешь, начинает разваливаться. Я долго искал способ видеть всё сразу: сколько гостей приехало, сколько уехало, какой доход за сутки, какая вилка по расходам, где затыки по обслуживанию. В итоге я выбрал PostgreSQL как центральную нервную систему всего бизнеса.

Проблема: пять Excel-таблиц и ночные сообщения

До перехода на единую базу у нас было классическое для property management месиво: одна таблица в Google Sheets для бронирований, другая для расходов, третья для контрактов, отдельный файл для показаний счётчиков воды и электричества, плюс переписки в WhatsApp как «база знаний» по текущим проблемам.

Менеджер из Ubud не видел, что происходит в Canggu. Бухгалтер не мог быстро сравнить расходы по виллам за месяц. Я ловил тревожные сообщения в три ночи от менеджеров, что «что-то пошло не так», и не мог быстро понять масштаб проблемы, потому что данные были размазаны по десятку источников.

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

Решение: PostgreSQL как единая точка правды

Я перенёс всё в одну PostgreSQL-базу. Сейчас в ней больше 25 000 записей: каждая бронь, каждый платёж, задачи персоналу, номера телефонов гостей, даже показания счётчиков воды и света — всё тянется в одну базу.

Структура получилась такая:

villas (16)              — все виллы с метаданными
├── bookings (8000+)     — бронирования из eZee PMS
├── payments (5000+)     — все платежи и комиссии
├── expenses (3000+)     — расходы по виллам
├── tasks (4000+)        — задачи персоналу
├── guests (2500+)       — база гостей
├── utility_readings     — счётчики воды/электричества
├── villa_contracts      — контракты аренды
└── daily_reports        — ежедневные сводки

Один SQL-запрос — и я вижу полную картину по любой вилле за любой период. Нет нужды открывать пять табличек и складывать цифры в голове.

Что это дало на практике

Первое и самое важное — скорость принятия решений. Раньше чтобы ответить на вопрос «сколько мы заработали на вилле #12 в марте» нужно было 20-30 минут ковыряния в таблицах. Сейчас — один запрос, три секунды.

Второе — автоматические дашборды. На базе PostgreSQL я построил систему ежедневных отчётов. Каждое утро в Telegram приходит сводка: доход за вчера, количество заездов/выездов, аномальные расходы, просроченные задачи. Не нужно ни у кого ничего спрашивать — данные сами приходят.

Третье — обнаружение аномалий. Когда все данные в одном месте, можно строить сравнительные отчёты. Если расход электричества на вилле #07 вдруг вырос в два раза — система это заметит и пришлёт алерт. Без единой базы такое ловится только постфактум, когда приходит счёт за месяц.

Связка с AI-ботами

PostgreSQL — это не просто хранилище. Это фундамент, на котором стоят все мои AI-боты. Голосовой ассистент Алиса отвечает гостям, вытягивая данные из базы в реальном времени. Рассыльщик проверяет актуальность предложений по виллам. Мониторинг финансов анализирует расходы и ищет аномалии.

Без единой базы каждый бот работал бы в своём информационном пузыре. С PostgreSQL все агенты видят одну и ту же картину мира — актуальную, консистентную, с историей изменений.

Почему не Firebase, не Airtable, не Google Sheets

Меня часто спрашивают, почему PostgreSQL, а не что-то попроще. Ответ прямой: масштаб и гибкость. Google Sheets тормозит уже на 5 000 строк. Airtable стоит денег и ограничивает количество записей. Firebase хорош для мобильных приложений, но для аналитических запросов неудобен.

PostgreSQL бесплатный, работает на нашем сервере, поддерживает сложные JOIN-запросы, транзакции, индексы. Я могу написать запрос, который за секунду покажет мне топ-5 вилл по доходу за квартал с разбивкой по каналам бронирования. Попробуйте это в Google Sheets.

Уроки внедрения

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

Правильный путь: начать с одного домена (я начал с бронирований), наладить синхронизацию с eZee PMS, убедиться что всё работает, и только потом переходить к расходам, контрактам и остальному. Весь процесс занял около трёх недель.

Вторая ошибка — не делать бэкапов с первого дня. Потерял данные за два дня из-за неудачного обновления скрипта. Теперь pg_dump запускается каждые 6 часов автоматически. Стоило мне это ровно одну строчку в crontab и ноль нервов с тех пор.

Ключевые выводы

  • Единая база данных устраняет рассинхронизацию между таблицами и ручной труд по сведению цифр
  • 25 000+ записей в PostgreSQL работают быстрее, чем 5 000 строк в Google Sheets
  • Все AI-боты используют одну базу — это обеспечивает консистентность данных по всей системе
  • Начинать миграцию с одного домена данных, а не всего сразу
  • Бэкапы pg_dump каждые 6 часов — обязательный минимум с первого дня

Читайте также

Подписаться на блог в Telegram

Читайте свежие кейсы об AI-автоматизации, системной архитектуре и масштабировании бизнеса.

Подписаться