Привет, Хабр! Меня зовут Алексей Быков, я занимаюсь развитием cloud-native-платформы для обработки данных Arenadata One (AD.ONE). В этой статье мы поговорим о neon-kubernetes-реализации PostgreSQL, её устройстве, особенностях и о том, почему классический подход к Postgres в Kubernetes не позволяет в полной мере использовать преимущества гибкой облачной инфраструктуры.

Тема не новая и активно развивается: уже давно существуют операторы (Zalando, Crunchy Data, CloudNativePG) для автоматизации развёртывания Postgres в Kubernetes. Однако они сохраняют монолитность базы, когда данные по-прежнему жёстко связаны с узлами, а горизонтальное или вертикальное масштабирование требует ручной настройки и остаётся непростым процессом. Подход Neon основан на полном разделении вычислений (compute) и хранилища (storage), что даёт нам возможность взглянуть на использование PostgreSQL в облаке по-новому, как на сервис с возможностью динамического масштабирования, мгновенного запуска инстансов, изолированных веток (branching) и других возможностей без необходимости в сложной инфраструктурной обвязке.

Хабр, привет! Меня зовут Алексей Быков, и я занимаюсь развитием Cloud Native платформы для обработки, хранения, анализа и управления данными Arenadata One в компании Arenadata. Современные высоконагруженные системы требуют гибкого масштабирования и отказоустойчивости для обеспечения стабильной производительности в условиях постоянно растущих объёмов данных. Когда речь идёт о PostgreSQL, развёрнутом в Kubernetes, перед инженерами встают особые вопросы: как упорядочить реплики для отказоустойчивости, каким образом настроить бэкапы и мониторинг, а главное — как корректно масштабироваться в облачной среде.

В этой статье мы рассмотрим, почему «ванильный» PostgreSQL в контейнерной среде может работать ненадёжно и какие механизмы применяются сегодня, чтобы сделать базу данных по-настоящему Cloud Native. Разберём ключевые аспекты классических инсталляций Postgres, проанализируем, в чём заключаются основные сложности их переноса в Kubernetes.