PlanetScale выпустила Neki, шардированный Postgres в статусе платформенного превью

PlanetScale выпустила Neki, шардированную версию Postgres, которая распределяет базу данных по нескольким серверам, но на каждом из них (на каждом шарде) работает настоящий, немодифицированный Postgres. Доступ открыт в статусе платформенного превью: опробовать продукт уже можно, но сама компания прямо говорит, что продакшн-нагрузки на Neki запускать не следует, платформа ещё меняется, и часть изменений будет несовместима с тем, что есть сейчас.

По словам PlanetScale, за спиной у компании, восемь лет эксплуатации одних из крупнейших в мире шардированных кластеров MySQL: тысячи промышленных нагрузок с миллионами запросов в секунду, где простой даже в несколько секунд становится публичным происшествием. Это опыт всего бизнеса PlanetScale, а не показатели самого Neki, цифр по производительности или числу внедрений именно для Neki в анонсе нет. Полтора года назад компания выпустила PlanetScale Postgres и с тех пор подключила к платформе несколько тысяч новых клиентов, часть из которых по масштабу сравнялась с крупнейшими клиентами компании на MySQL. PlanetScale пишет, что раз за разом наблюдала, как эти команды подходят к потолку одной машины Postgres. Переход на более мощный инстанс давал время, но не решал проблему: рано или поздно достаточно мощных машин просто не остаётся, а трудности с ростом нагрузки не масштабируются линейно вместе с добавлением процессорных ядер и пропускной способности по операциям ввода-вывода (IOPS).

Компания перечисляет знакомый набор проблем быстрорастущей базы на Postgres: таблицы, которые становится рискованно вакуумировать (vacuum) или индексировать без влияния на текущий трафик, бэкапы, растягивающиеся на часы, лимиты на количество соединений, окна обслуживания для изменения схемы и исчерпание счётчика транзакций (wraparound). Из существующих решений каждое требует чем-то пожертвовать: шардирование на уровне приложения перекладывает логику маршрутизации на код самой команды, а Postgres-«совместимые» распределённые базы, по формулировке PlanetScale, скрывают от пользователя ключ шардирования, отбирают привычные расширения и добавляют сложность и задержки, которые трудно отлаживать. Neki построен на другом принципе, не подменять Postgres и не обходить его, а оставить настоящий Postgres на каждом шарде.

У архитектуры Neki четыре основные части. Приложение подключается к роутеру Neki по стандартному протоколу Postgres, поэтому имеющиеся драйверы, ORM и строка подключения не меняются; роутер разбирает запрос полноценным парсером Postgres, буферизует его, а распределённый планировщик решает, какие шарды должны его выполнить, после чего результаты собираются обратно в один поток, роутеры масштабируются и вертикально, и горизонтально, поэтому ни один из них не становится узким местом. Каждый шард, это полноценный кластер Postgres с одним главным узлом (primary) и минимум двумя репликами в трёх зонах доступности, без изменённого движка хранения: расширения, поддержка SQL и производительность ведут себя так же, как у обычного Postgres. Шарды объединяются в группы, и каждая группа настраивается под свою нагрузку отдельно, размер инстанса, число реплик, объём хранилища, параметры Postgres и набор расширений. Рядом с каждым экземпляром Postgres работают вспомогательные процессы-сайдкары: поскольку Neki управляет соединением с обеих сторон, и со стороны роутера, и со стороны Postgres, он подбирает размер пула соединений под то, что инстанс реально способен обслужить, а не оценивает это снаружи, как в связке с обычным PgBouncer. Плоскость управления следит за состоянием каждого узла, проводит плановые переключения, обрабатывает внеплановые отказы и координирует решардинг, изменения схемы и обновления версий. Связывает всё это топология данных, JSON-конфигурация, которая определяет ключ шардирования (по какой колонке и как хешировать значение) и группы шардов (сколько шардов занимает набор таблиц и какие именно); роутеры кешируют эту топологию и обращаются к ней при построении каждого плана запроса.

Изменение схемы, обновление версий, плановые переключения и обработка отказов, импорт данных и решардинг в Neki работают как встроенные рабочие процессы, а не как отдельные операции с окном обслуживания: рабочий процесс поднимает новые узлы, догоняет их репликацией, переключает трафик и выводит из эксплуатации старые узлы, и всё это через то же подключение psql, которым пользуется приложение. Шардировать с первого дня не обязательно: Neki можно запустить как один главный узел с репликами и уже на этом этапе получить более качественный пул соединений, изменение схемы без блокировок, обновления без простоя и мониторинг состояния, а когда мощности одной машины перестанет хватать, провести решардинг как рабочий процесс над тем же кластером. Кроме шардирования, Neki включает и остальные функции PlanetScale, которыми компания уже пользуется: Insights, рекомендации по схеме, ветвление баз данных (branching) и MCP.

Чтобы попробовать Neki, нужно войти в PlanetScale, включить платформенное превью и создать кластер Neki, документация компании описывает архитектуру и то, как шардировать данные. Отдельно PlanetScale предлагает частную демонстрацию командам с большим кластером Postgres: компания разбирает схему и паттерны запросов заказчика и даёт конкретные рекомендации по шардированию. Вопросы и проблемы, возникшие во время превью, принимаются через тикет поддержки или Discord-канал компании.

Ключевые факты

PlanetScale выпустила Neki, шардированный Postgres, но доступ пока открыт только в статусе платформенного превью: компания прямо говорит, что продакшн-нагрузки на Neki запускать не следует, потому что архитектура ещё меняется.
На каждом шарде работает настоящий, немодифицированный Postgres, один главный узел (primary) и минимум две реплики в трёх зонах доступности; приложение подключается к роутеру Neki по стандартному протоколу Postgres, поэтому существующие драйверы, ORM и строка подключения не меняются.
Распределение таблиц по шардам задаётся JSON-конфигурацией, топологией данных: в ней выбирается ключ шардирования и группы шардов, а каждая группа настраивается отдельно, размер инстанса, число реплик, хранилище, параметры Postgres и набор расширений.
Изменение схемы, обновление версий, переключения при отказах, импорт данных и решардинг выполняются как встроенные рабочие процессы через то же подключение psql, которым пользуется приложение, без отдельных окон обслуживания.
Шардировать с первого дня не обязательно: Neki можно запускать как один главный узел с репликами и получить более качественный пул соединений и обновления без простоя уже на этом этапе, а решардинг сделать позже как рабочий процесс над тем же кластером.

Почему это важно

Рано или поздно один сервер Postgres упирается в потолок, сама PlanetScale перечисляет типичные симптомы: таблицы, которые становится рискованно вакуумировать или индексировать без влияния на трафик, бэкапы, растягивающиеся на часы, лимиты на количество соединений, окна обслуживания для изменения схемы, исчерпание счётчика транзакций (wraparound). До Neki у команды было два варианта, и оба требовали чем-то жертвовать: писать логику шардирования внутри собственного приложения либо переходить на Postgres-«совместимую» распределённую базу, которая, по описанию PlanetScale, прячет ключ шардирования, отбирает часть расширений и добавляет сложность и задержки, которые трудно отлаживать. Neki предлагает третий путь, шардированный Postgres, где на каждом шарде остаётся настоящий, немодифицированный Postgres с привычными расширениями и поведением.

Кому это важно

Прежде всего, командам, чья база на Postgres уже подошла к потолку одной машины или растёт достаточно быстро, чтобы этот потолок стало видно: именно такой профиль PlanetScale описывает у части своих клиентов на PlanetScale Postgres, которые по масштабу сравнялись с крупнейшими клиентами компании на MySQL. Также, тем, кто уже реализовал шардирование на уровне приложения своими силами и хочет вынести эту логику из кода, и тем, кто рассматривал Postgres-«совместимые» распределённые базы, но не готов терять доступ к ключу шардирования и обычным расширениям Postgres. Наконец, это касается существующих клиентов PlanetScale: компания обещает и внутри Neki тот же набор функций, которым они уже пользуются, Insights, рекомендации по схеме, ветвление баз данных и MCP.

Как это применить

Доступ открыт как платформенное превью: войти в PlanetScale, включить превью и создать кластер Neki, документация компании описывает архитектуру и то, как шардировать данные. Подключение не меняется: приложение продолжает работать со стандартным протоколом Postgres через роутер Neki, поэтому драйверы, ORM и строка подключения остаются прежними. Дальше нужно описать топологию данных в JSON: выбрать ключ шардирования (по какой колонке и как хешировать значение) и разбить таблицы на группы шардов, для каждой задав свои настройки, размер инстанса, число реплик, хранилище, параметры Postgres и расширения. Шардировать с первого дня не обязательно: можно начать с одного главного узла с репликами, получить уже на этом этапе более качественный пул соединений, изменение схемы без блокировок и обновления без простоя, а решардинг провести позже как рабочий процесс над тем же кластером. Для крупных существующих кластеров Postgres PlanetScale предлагает отдельную частную демонстрацию с разбором конкретной схемы и паттернов запросов. Оговорка от самой компании: это превью, не для продакшена, и часть изменений будет несовместима с тем, что есть сейчас.

Можно ли доверять

Опыт, на который ссылается PlanetScale, проверяем хотя бы по собственному треку компании: восемь лет эксплуатации крупных шардированных кластеров MySQL, запуск PlanetScale Postgres полтора года назад и несколько тысяч клиентов, подключённых с тех пор. Но эти цифры, про бизнес PlanetScale в целом, а не про сам Neki: анонс не приводит ни одной цифры по производительности или числу внедрений именно для Neki, ни даты полного релиза, ни цен, ни списка облаков и регионов, где сервис будет доступен. Текст подписан от имени компании целиком, без конкретного автора или представителя, и не содержит ни одной внешней оценки или отзыва клиента о самом Neki, только описание архитектуры и статус платформенного превью. Иными словами, доверие здесь опирается на репутацию PlanetScale как поставщика шардированных баз, а не на проверенные результаты самого продукта: по собственному определению компании, Neki ещё не готов к продакшн-нагрузкам.

Риски и подводные камни

Формально это ещё не готовый продукт, а превью: PlanetScale прямо говорит, что продакшн-нагрузки на Neki запускать не следует, и что архитектура продолжит меняться, а часть изменений будет несовместима с тем, что настроено сейчас. В анонсе нет ни даты полной доступности, ни цен, ни списка облаков и регионов, планировать бюджет или миграцию по этому тексту пока не на что. Собственных цифр по производительности или внедрениям у Neki тоже нет: все метрики в посте, про многолетний MySQL-бизнес PlanetScale, а не про новый продукт, так что первые пользователи будут первыми, кто проверит его на реальной нагрузке. Neki доступен только через аккаунт PlanetScale, это управляемый сервис платформы, а не отдельный инструмент для самостоятельной установки, и выбор в его пользу, это заодно выбор PlanetScale как поставщика базы данных. И PlanetScale критикует Postgres-«совместимые» распределённые базы конкурентов, не называя ни одной по имени, сравнить это с конкретными альтернативами читателю придётся самостоятельно.