Сойер Бейтман большую часть своей карьеры размышлял о доставке и логистике. Осенью 2024 года Сойер основал новую компанию Shipsidekick. Она сфокусирована на «следующем уровне логистического стека», объединяя управление складами, заказами и транспортировкой в единую платформу для грузоотправителей и 3PL-операторов, с ИИ-помощником, который помогает командам управлять операциями. Shipsidekick представляет собой веб-приложение со всеми вытекающими отсюда экранами, отчетами и пользовательскими сессиями.
«Я не специалист по базам данных», — заявил Сойер собравшимся на встрече пользователей ClickHouse в Ванкувере в августе 2026 года. Это история о том, как основатель-«универсал» (как он сам себя называет) и его команда выбрали ClickHouse Managed Postgres, мигрировав с Neon, и как эта миграция сделала запросы примерно в 10 раз быстрее, а саму базу данных — гораздо надежнее.
Имея за плечами опыт создания компаний на базе монолита Ruby on Rails на MySQL более десяти лет назад, Сойер захотел попробовать более современный фреймворк. Он создал Shipsidekick как приложение на Next.js, развернутое на Vercel. Следуя стандартным на тот момент рекомендациям, он объединил бессерверное приложение с бессерверным провайдером Postgres и остановил свой выбор на Neon.
«Некоторое время Neon работала нормально», — говорит он. Однако все изменилось, когда в Shipsidekick включили новый механизм вычислений Vercel Fluid. Гибридная модель оказалась дешевле и производительнее на стороне приложения, но она сразу же создала проблемы с пулами соединений Postgres.
Старый стек пулинга, объясняет Сойер, состоял из трех уровней, и исправление одного неизбежно ломало другой. Prisma, ORM от Shipsidekick, поддерживает собственный внутренний пул соединений. Vercel требует создания пула pg, передачи его в Prisma и подключения к плагину, который распределяет соединения между сессиями вычислений Fluid. Neon работает поверх инстанса PgBouncer, который заявляет 10 000 пулированных соединений, «но они делятся между неизвестно каким количеством людей», отмечает Сойер.
«У нас было просто массу проблем при попытке настройки», — добавляет он. «Как бы мы ни пытались всё сбалансировать, мы упирались в исчерпание пула и таймауты... у нас истощался либо пул Prisma, либо пул Vercel Fluid. Если мы убирали какие-то из этих пулов, то получали ошибки от Neon из-за достижения лимитов их PgBouncer».
Сбои стали легко прогнозируемыми. «Мы падали ровно в тот момент, когда переходили отметку примерно в 3000 соединений, что бы мы ни делали», — говорит он. Инстанс постоянно упирался в лимит процессора, а оперативная память была заполнена до отказа. Понедельник, когда клиенты оформляют заказы после выходных, был самым тяжелым днем недели. «Нам приходилось отключать нашу базу данных Neon каждый понедельник, когда начинался ажиотаж».
Поддержка Neon мало чем помогла. На один срочный тикет, поданный во время падения базы данных, не отвечали в течение 38 часов. Другой занял шесть дней. Тем временем Neon (приобретенная в 2025 году компанией Databricks) продолжала присылать письма с предложением Shipsidekick перейти на Databricks Lakebase. «Как технологические ограничения, так и поддержка вендора не отвечали нашим потребностям», — говорит Сойер. «Нам приходилось самостоятельно справляться со множеством стрессовых ситуаций».
К середине 2026 года Сойер довел масштабирование Neon до предела ее диапазона автоматического масштабирования — 16 вычислительных юнитов (около 64 ГБ ОЗУ). «Мы платили очень много», — говорит он, отмечая, что даже при счете почти в 2300 долларов в месяц коэффициент попадания в кэш составлял не более 30–35%, а клиенты писали на почту по поводу медленной загрузки. «В тот момент я решил, что нам нужно новое решение».
Они оценили PlanetScale, предложение Metal которого с хранилищем на базе NVMe выглядело привлекательно. Но схема высокой доступности PlanetScale требует двух реплик, поэтому «вы по сути платите за три базы данных», говорит Сойер. По его подсчетам, это обошлось бы в 4000–5000 долларов в месяц.
Затем он увидел публикацию ClickHouse на Hacker News. В ней показывалось, как команда масштабировала PgBouncer до четырехкратной пропускной способности в ClickHouse Managed Postgres. «Поскольку мы столько боролись с PgBouncer, мне это показалось очень интересным», — говорит Сойер.
Его привлекло и несколько других факторов. Во-первых, по его словам, «ценообразование было фантастическим». ClickHouse Managed Postgres также предлагала больше вариантов инстансов, чем PlanetScale, с «идеальным балансом процессора, памяти и хранилища». Он выбрал оптимизированный под хранилище инстанс с 16 vCPU, 128 ГБ ОЗУ и 3 ТБ памяти с одной резервной копией. Даже по полной цене он оказался значительно дешевле его оценок для PlanetScale.
Частично разница заключается в том, что ClickHouse позволяет использовать одну резервную копию вместо двух обязательных. «Вместо того чтобы обеспечивать консенсус при записи ваших транзакций, они просто передают транзакции в режиме реального потока на резервный узел», — объясняет он. «Возможно, вы потеряете секунду записей в случае необходимости аварийного переключения. Меня это устраивает ради экономии трети стоимости и повышения производительности записи».
Еще одним достоинством стала документация. «Документация, которую ClickHouse подготовила для Postgres, просто невероятна», — говорит Сойер. «Это не ощущается как новый продукт. Ничего в документации не было неверным, устаревшим или вводящим в заблуждение».
И, конечно же, люди. Изучая продукт, Сойер нашел ветку на Reddit, где Сай Срирампур, возглавляющий ClickHouse Managed Postgres после приобретения его прежней компании PeerDB, публично отвечал на вопросы. «Видя, как команда ClickHouse открыто общается с комментаторами, — говорит Сойер, — мы прониклись большим доверием».
Сойер создал учетную запись 16 июля. Сай лично написал ему на почту в тот же день, и всего через пару часов они уже общались в общем канале Slack. Такая оперативность стала приятной переменой. «Я не сомневайся, что если бы у нас упал ClickHouse, мы получили бы ответ в течение минут, если не секунд», — говорит он.
Он называет процесс миграции «безумно простым». Команда следовала руководству ClickHouse по настройке источника Neon Postgres: включить логическую репликацию на Neon, создать ClickPipe на панели источников данных в консоли ClickHouse и запустить репликацию. На тот момент у Shipsidekick было около 500 ГБ данных. Сай оценивал, что репликация займет полтора дня. В итоге все заняло четыре или пять часов.
На встрече в Ванкувере Сойер предупредил о небольшой трудности всех, кто пойдет по тому же пути. Задание cron в приложении выполняло несколько транзакций, которые при репликации «на лету», а не в их конечном состоянии, привели к срабатыванию частичного уникального индекса в таблице счетов. «Решение оказалось очень простым», — говорит Сойер: удалить проблемный индекс, дождаться окончания репликации, а затем воссоздать его.
Он отмечает, что ClickPipes справились с этим сбоем изящно. «Несмотря на ошибку в репликации, ничего не потерялось, — говорит он. — Система буквально просто ждала, пока ошибка не будет устранена, а затем все продолжилось так, будто ничего не случилось».
Другим открытым вопросом было пулинг соединений. Трафик Shipsidekick по своей природе имеет пиковые нагрузки. Волна вебхуков Shopify может мгновенно увеличить количество запросов приложения с нуля до 10 000 в секунду. На Vercel это означает запуск множества экземпляров функций, каждый из которых имеет собственный пул. Сойер спросил команду ClickHouse, как настроить PgBouncer для бессерверной среды. Оказалось, что настраивать ничего не нужно. ClickHouse Managed Postgres поставляется с инстансом PgBouncer для каждого сервера, поэтому Shipsidekick убрала пулы Vercel и подключается напрямую к нему. «Короче говоря, никаких проблем не возникло», — говорит Сойер.
Миграция завершилась в воскресенье, так как Сойер хотел провести переключение на выходных. Понедельник, который раньше был самым напряженным днем недели, прошел незаметно. «Было тихо, как в лесу», — говорит он.
Преимущества проявились сразу же. В ClickHouse Managed Postgres загрузка ЦП обычно составляет 5–10%. «Это потрясающе видеть после того, как она боролась на уровне 100% в режиме 24/7 на Neon», — говорит Сойер. Количество подключений к реальной базе данных Postgres в любой момент времени колеблется от одного до 200.
«PgBouncer в ClickHouse Managed Postgres отлично справляется с обработкой всего, что происходит на Vercel. Мы даже не пытаемся как-то контролировать пиковый характер запросов. Всё просто отлично. Коэффициент попадания в кэш стал огромным достижением, подскочив с 30–35% до 99%.» — Сойер Бейтман, основатель и генеральный директор Shipsidekick
«PgBouncer в ClickHouse Managed Postgres отлично справляется с обработкой всего, что происходит на Vercel. Мы даже не пытаемся как-то контролировать пиковый характер запросов. Всё просто отлично. Коэффициент попадания в кэш стал огромным достижением, подскочив с 30–35% до 99%.»
— Сойер Бейтман, основатель и генеральный директор Shipsidekick
Учитывая этот скачок коэффициента попадания в кэш и хранилище на базе NVMe в ClickHouse Managed Postgres, которое удерживает данные на быстрых локальных дисках, а не в сетевом хранилище, производительность отличается как небо и земля. «Время выполнения наших запросов просто рухнуло», — говорит Сойер.
Он запустил параллельный тест со старым инстансом Neon, который все еще был развернут, но без нагрузки. Выгрузка данных о доставке за месяц (примерно 500 000 строк) заняла минуту и 20 секунд на Neon и около 6 секунд на ClickHouse. Данные за два месяца, которые на Neon вообще не удавалось получить, вернулись в ClickHouse за 20 секунд. «В среднем это в 10 раз быстрее, чем Neon, а в лучшем случае — кажется, бесконечно быстрее, — говорит он, — потому что половину времени Neon просто не работал».
В Neon у Shipsidekick был небольшой и дешевый репликатор для чтения, на который указывали все агенты искусственного интеллекта и MCP-серверы. Реплики чтения в ClickHouse Managed Postgres в настоящее время должны соответствовать размеру (и цене) первичной базы данных, поэтому Сойер сначала пропустил этот шаг и вместо этого предоставил агентам роль только для чтения на основной базе данных. «Какое-то время это было нормально», — говорит он, пока агент одного из членов команды не выполнил запрос, который оставался незамеченным в течение нескольких дней, скрытый в вызове инструмента, в результате чего загрузка ЦП подскочила до 40–50%. «Я подумал: ладно, это тревожный звонок. Ваши ИИ-чтения могут повлиять на производительность основной базы данных».
Чтобы предотвратить это, они внедрили тайм-ауты операторов и транзакций для роли только для чтения. Более долгосрочным решением стало создание выделенной реплики чтения для агентов.
С момента миграции Сойер изучал, для чего еще можно использовать ClickHouse. Команда уже использует ClickHouse Agents для анализа производительности, поскольку у агентов есть доступ к логам, статистике Postgres и данным о медленных запросах. «Это было прекрасным подспорьем, помогшим нам понять, что делать дальше и как улучшиться», — говорит он.
Он также спрашивал агентов, какие рабочие нагрузки следует перенести непосредственно в ClickHouse, причем внутриприложенные дашборды Shipsidekick стали естественным первым кандидатом. «У нас есть дашборды в приложении, но они медленные», — говорит Сойер. Поскольку аналитика компании перерастает Postgres, команда имеет отличные возможности для совершения этого шага. «Теперь у меня большая вера в ClickPipes, потому что миграция прошла так успешно, — добавляет он. — Когда придет время реально начать использовать ClickHouse, будет очевидно, кого мы выберем».
Для Shipsidekick важнее всего то, как приложение воспринимается клиентами. Сойер вспоминает разговор через несколько дней после миграции на ClickHouse Managed Postgres с тем же клиентом, который писал по электронной почте о медленной загрузке. «Они сказали: „Я не знаю, что вы сделали, но теперь приложение работает быстро“. А я ответил: „Я знаю, что я сделал. Мы избавились от Neon“».
От еженедельных сбоев и многодневного ожидания поддержки до миграции за выходные и базы данных, которая едва замечает свой самый загруженный день — для Shipsidekick это был грандиозный поворот.
«Нам очень нравится эта единая платформа, управляющая ClickHouse и Postgres одновременно. Все работает быстро, клиенты счастливы, и мы тоже». — Сойер Бейтман, основатель и генеральный директор Shipsidekick
«Нам очень нравится эта единая платформа, управляющая ClickHouse и Postgres одновременно. Все работает быстро, клиенты счастливы, и мы тоже».
— Сойер Бейтман, основатель и генеральный директор Shipsidekick
/)
/)
