OrioleDB и Neon часто воспринимаются как «следующее поколение Postgres», но они решают разные задачи и по‑разному устроены внутри.
В этом материале разбираем архитектуру, масштабирование, обработку WAL, VACUUM и проблему раздувания данных, разделение хранилища и вычислений, производственную готовность и реальные сценарии использования. К концу статьи вы поймёте, когда выбирать OrioleDB с его UNDO‑MVCC, копи‑он‑райт чекпойнтами и кешем на squizzled‑указателях, а когда — Neon с его удалённым сториджем, моментальными ветвлениями, read‑replica «в один клик» и масштабированием до нуля.
Введение: почему OrioleDB и Neon так часто путают
В сообществе PostgreSQL нередко вспыхивают обсуждения о том, чем на самом деле различаются OrioleDB и Neon. На первый взгляд оба проекта обещают «next‑gen Postgres», оба умеют работать с облачными хранилищами и оба активно развивают идею современного масштабируемого хранилища для PostgreSQL. Но сходство заканчивается на уровне лозунгов: внутри — два принципиально разных пути эволюции PostgreSQL, с разными компромиссами и зонами силы.
Эта статья системно разложит различия по полочкам — от архитектуры и модели данных до масштабирования, отказоустойчивости, эксплуатационных практик и производственной зрелости. Важный контекст: OrioleDB — это расширение и новый Table Access Method (TAM), фокус которого — производительность одной машины, устранение блоута и предсказуемая латентность за счет UNDO‑MVCC, копи‑он‑райт чекпойнтов и тонкого WAL на уровне строк. Neon — это удалённое, многоарендное хранилище и «тонкие» compute‑ноды, позволяющее мгновенно ветвиться, ставить read‑реплики на лету и «складывать» нагрузку до нуля, когда БД простаивает.
Ниже представлены ключевые выводы наперёд:
- OrioleDB — про сырой односерверный throughput, минимизацию блоута и отказ от рутины VACUUM за счёт UNDO, а также экономию IOPS через строковый WAL и копи‑он‑райт чекпойнты.
- Neon — про разделение compute и storage, мгновенные ветвления и эластичность; compute‑ноды близки к vanilla‑Postgres по масштабируемости CPU, но компенсируют это возможностью добавлять read‑реплики и управлять жизненным циклом вычислений как сервисом.
- Оба проекта двигают Postgres в новую эпоху, но «тянут» его в разные стороны: OrioleDB — в глубину эффективности внутри узла, Neon — в ширину облачной управляемости и мультиарендности.
Коротко о проектах: что это такое «с высоты полёта»
OrioleDB
OrioleDB — расширение PostgreSQL, реализующее собственный Table Access Method вместо стандартного Heap. Ключевые моменты:
- MVCC на основе UNDO, что в корне меняет работу с версионностью и сильно сокращает раздувание (bloat).
- Копи‑он‑райт чекпойнты и компактный строковый WAL, что снижает нагрузку на запись и улучшает локальность IO.
- Эффективный слой кеширования в общей памяти с использованием squizzled pointers, снимающий традиционные узкие места буфер‑менеджера и WAL writer.
- Экспериментальный режим S3: холодные данные «ссылаются» в объектное хранилище, локальный диск работает как кеш, возможна синхронизация на чекпойнтах и архивирование WAL в S3. В перспективе — подключение нескольких реплик к одному S3 (локальное хранилище на репликах по‑прежнему нужно).
Neon
Neon — это сервис и стек, отделяющий хранение от вычислений. Compute‑ноды используют стандартный Heap, но WAL стримится в Safekeepers (реплицируемый лог), а страницы читаются с Page servers, которые держат горячие блоки на SSD и выгружают холодные «слои» в S3‑совместимое хранилище. Это обеспечивает мгновенное ветвление (branching), моментальные read‑реплики и способность «масштабироваться до нуля». Хранилище — многоарендное и кросс‑AZ.
Архитектура и модель данных: TAM против удалённого сториджа
Table Access Method и UNDO‑MVCC в OrioleDB
В классическом PostgreSQL стандартный Heap хранит версии строк в страницах таблицы, старые версии убираются (или помечаются) VACUUM‑ом, отсюда возникают вопросы блоута, конфликты за горячие страницы и чрезмерный IO при интенсивных обновлениях. OrioleDB, как альтернативный TAM, переносит акцент на UNDO‑журналирование:
- При обновлениях новые версии не «нашлёпываются» поверх, а фиксация видимости управляется через UNDO‑записи, что позволяет гораздо точнее контролировать жизненный цикл версий.
- Это снижает блоут, а рутинные VACUUM‑проходы становятся не нужны: фоновая работа по очистке превращается в управление UNDO и слияние разреженных страниц.
- Уровень гранулярности WAL — строковый, а не блочный, что уменьшает объём записи и экономит IOPS.
Отдельная инновация — кеширование в shared memory на основе squizzled pointers. В классическом пути многие нагрузки «упираются» в глобальные блокировки буфер‑менеджера и координацию вокруг записи WAL. Новый кеш и формат WAL в OrioleDB стремятся эти узкие места обходить.
Neon: расщеплённые роли compute и storage
Neon оставляет стандартный TAM (Heap) внутри compute‑ноды, зато радикально меняет слой хранения:
- WAL подаётся в quorum из Safekeepers, обеспечивая быстрый и надёжный журнал.
- Чтение страниц идёт с Page servers; они держат «горячее» на локальных SSD, а «слои» — в объектном хранилище. Такая схема даёт бесшовные снапшоты и ветвления, ведь слои — это по сути компактные версии состояний, основанные на истории WAL и периодических чекпойнтах.
- Так как compute не содержит долговечного состояния (кроме содержимого shared buffers, которое восстановимо), эти ноды легко запускать, останавливать, клонировать. Это формирует эксплуатационные возможности, которых обычно нет в «монолитной» инсталляции Postgres.
CPU‑масштабирование: вертикаль против горизонта
OrioleDB: снятие узких мест внутри узла
OrioleDB уменьшает контенцию вокруг буфер‑менеджера и WAL‑writer за счёт новой кеш‑прослойки и строкового WAL. Для «толстых» машин с большим количеством vCPU и высокоинтенсивной смешанной нагрузкой (много чтений и записей) это даёт ощутимый выигрыш по масштабированию на одном узле. В сценариях, где важна предсказуемая латентность и высокая плотность R/W в рамках одной большой ВМ, OrioleDB раскрывает себя наилучшим образом.
Neon: стандартная CPU‑масштабируемость compute плюс лёгкие read‑реплики
Compute‑ноды Neon масштабируются близко к vanilla PostgreSQL по CPU, поскольку внутри остаётся классический Heap и привычный стек. Но Neon компенсирует это свойством мгновенно добавлять read‑only compute‑ноды, «подцеплённые» к одному и тому же хранилищу. Для рабочей нагрузки, где чтения преобладают (или читающие пики периодически накрывают систему), это очень мощный рычаг: горизонтальные read‑реплики без сложной ручной репликации и с минимальными усилиями по управлению.
IO‑масштабирование: локальность против теоретической «бесконечности»
OrioleDB: экономия IOPS и локальный NVMe
Копи‑он‑райт чекпойнты улучшают локальность записи, а строковый WAL — снижает её объём. На современном NVMe‑хранилище это превращается в предсказуемую и быструю работу на высоких IOPS, уменьшая хвосты латентности. Для OLTP‑нагрузок с активной записью это зачастую важнее любых удалённых трюков — локальная дисковая подсистема по задержкам почти всегда бьёт сетевую.
Neon: распределённое хранилище и цена сети
Neon строит распределённую сетевую подсистему хранения, которая теоретически масштабируется практически без ограничений. Сильная сторона — ёмкость, многоарендность, надёжность в нескольких зонах доступности, мгновенное ветвление. Слабая сторона — сетевые задержки: чтение страницы в 8 KB по сети, обращение к Page server и взаимодействие с Safekeepers вносят дополнительную латентность по сравнению с локальным NVMe. В обмен вы получаете эластичность, мгновенные копии и централизованное хранение состояния.
VACUUM и блоут: разные философии
OrioleDB: UNDO и слияние разрежённых страниц
За счёт UNDO как основы MVCC, OrioleDB отказывается от рутинного VACUUM и значительно снижает риск блоута. Это особенно ценно там, где обновления интенсивны, а окна обслуживания минимальны. Сочетание UNDO‑логов (на уровне блоков и строк) и автоматического слияния «пустых» страниц поддерживает компактность данных без периодических «разгребаний».
Neon: стандартный VACUUM плюс упругость хранилища
Neon использует штатный VACUUM на первичной compute‑ноде. Формально это означает, что фундаментальная природа Heap никуда не делась: борьба с блоутом — через аспекты настройки автовакуумов, индексации и практик эксплуатации. Разница в том, что масштабируемая, распределённая подсистема хранения сглаживает «цену» этих операций: хранилище проще «переварит» всплески и обеспечит место, а моменты с VACUUM‑паузациями скрываются за горизонтальной эластичностью и оперативным управлением compute‑нодами.
Разделение хранения и вычислений: как это меняет эксплуатацию
Neon: hard split с первого дня
Архитектурный замысел Neon — полностью развязать вычисления и хранение: compute статичен лишь в пределах shared memory, а само состояние БД живёт в реплицируемом сетевом хранилище. Это открывает:
- Мгновенные ветвления (branching) и клоны баз без копирования терабайт данных.
- Scale‑to‑zero: нет нагрузки — нет «горящих» вычислительных ресурсов.
- Read‑реплики на лету: подключение дополнительных compute‑нод на общую «линию времени» данных.
- Быстрые восстановления и миграции между зонами доступности.
OrioleDB: локальный диск как кеш с S3‑бэкендом (экспериментально)
OrioleDB может работать в режиме S3, где горячие данные на локальном носителе, а холодные — в объектном хранилище. На чекпойнтах — синхронизация; WAL архивируется в S3. Это даёт преимущества по стоимости хранения и позволяет, подобно Neon, опускать вычислительные ресурсы до нуля при простое. Однако архитектура остаётся cache‑first: локальный диск — не опция, а необходимость, а подключение нескольких реплик к одному S3 пока в разработке. То есть разделение compute/storage здесь не жёсткое, а гибридное, с сильной опорой на локальный кеш для производительности.
Производственная готовность и поддержка
Статус OrioleDB
По состоянию на текущие публичные данные, OrioleDB находится в статусе публичной беты (например, beta10), и команда прямо указывает: использовать в проде пока не рекомендуется. Для работы требуется сборка PostgreSQL 17 с патчами; часть изменений находится в процессе апстрима, но ещё не вошла в основной релиз. Поддержка — коммьюнити‑уровня (в частности, через GitHub). OrioleDB доступен в экспериментах у ряда провайдеров PaaS (например, в Supabase для не‑прод проектов).
Статус Neon
Neon объявлял GA на AWS в августе 2024 года, далее — GA на Azure с нативной интеграцией в мае 2025 года. Compute‑ноды Neon тоже используют пропатченный PostgreSQL (улучшенный WAL‑стриминг, хуки удалённого хранилища, настройки fsync). Патчи поддерживаются командой Neon и регулярно ребейзятся на новые мажорные версии PostgreSQL, пока upstream‑дискуссии продолжаются. На бизнес/энтерпрайз тарифах — 24×7 поддержка, SLA 99.95%, публичная статус‑страница и мульти‑регионные развёртывания.
WAL и чекпойнты: строка против страницы
OrioleDB: строковый WAL и copy‑on‑write
Переход к строковому WAL уменьшает объём записи по сравнению с блочными журналами, что особенно заметно в записях мелких UPDATE/INSERT. Copy‑on‑write чекпойнты улучшают локальность записи и позволяют контролируемо сбрасывать состояние, минимизируя «перемешивание» IO. В сумме это даёт меньше IOPS на единицу полезной работы и более предсказуемую задержку на пиках активности чекпойнтов.
Neon: WAL как «кровеносная система» удалённого хранилища
В Neon WAL — это основа согласованности между compute и хранением: журнал стримится на Safekeepers, а Page servers восстанавливают страницы из слоёв и истории WAL при чтении. Это архитектурно элегантно для ветвления и снапшотов, но естественным образом добавляет сетевые операции. Сильная сторона — быстрые клоны, ответвления на любой точке времени и лёгкие read‑реплики без тяжёлого логического репликационного контура на стороне клиента.
Кеширование и память: squizzled‑указатели против классики
OrioleDB: новый слой shared‑memory кеша
Один из самых недооценённых источников ускорений в OrioleDB — новый кеш‑слой, заменяющий традиционный буфер‑менеджер в части горячего пути. Использование squizzled pointers снижает накладные расходы на синхронизацию и даёт более высокую пропускную способность в условиях конкурентного доступа. В сочетании с UNDO‑MVCC это уменьшает вероятность «горячих» страниц и минимизирует обратное давление на систему.
Neon: знакомая модель для DBA
Compute‑ноды Neon по ощущению для DBA — «почти обычный Postgres»: shared_buffers, plan‑кеши, те же принципы настройки памяти. Это снижает порог входа и облегчает перенос существующих практик эксплуатации. Цена — вы по‑прежнему живёте с особенностями Heap, VACUUM и block‑level WAL, компенсируя их преимуществами удалённого, управляемого хранилища.
Сетевые задержки, локальность данных и «ценность близости»
Для многих OLTP‑нагрузок важна не только средняя задержка, сколько хвост распределения — P95–P99. На локальном NVMe хвосты обычно короче, чем в сетевом доступе к страницам. Поэтому:
- Если для вас критичны кратчайшие задержки и минимальная вариативность, подход OrioleDB с локальным кешем и строковым WAL может оказаться предпочтительным.
- Если основная цель — управляемость, быстрые клоны, учебные среды, короткоживущие фиче‑ветки, масштабирование под пики чтений, Neon превосходит альтернативы именно как сервис, а не как «движок IO» одного узла.
Репликация, высокая доступность и отказоустойчивость
Neon
Neon по умолчанию «дышит» как распределённый сервис: Safekeepers держат журнал в кворуме, Page servers реплицируют слои между AZ, compute‑ноды можно быстро переключать и масштабировать. Практики высокой доступности встроены в саму архитектуру. Добавление read‑реплик — дело секунд; переключение compute между AZ — штатная операция.
OrioleDB
OrioleDB наследует возможности HA от Postgres‑стека и добавляет свой взгляд через S3‑режим (экспериментально). Идея заключается в том, чтобы хранить холодные данные в объектном хранилище и на чекпойнтах отражать горячее состояние, что упрощает восстановление и уменьшает требования к локальной ёмкости. Однако полноценная «общая» слойная модель и мгновенные реплики «как в Neon» — не цель OrioleDB; задача другая: максимально эффективный single‑node с возможностью дешёвого хранения холодных слоёв.
Типы нагрузок: где кто сильнее
Когда выбирать OrioleDB
- Высокая интенсивность записи и обновлений, требования к минимальной латентности и узким хвостам задержек.
- Чувствительность к блоуту и нежелание тратить инженерное время на настройку и мониторинг VACUUM.
- Большие ВМ с быстрым локальным NVMe, где вертикальное масштабирование оправдано и экономически, и технически.
- Стабильный SLA по задержке важнее мгновенных снапшотов/ветвлений, а клоны БД создаются относительно редко.
Когда выбирать Neon
- Нужны «ветки» баз для фиче‑разработки, тестирования гипотез, прогона миграций — быстро и без копирования TB данных.
- Нужны дешёвые read‑реплики «по требованию» для BI/аналитики, периодических отчётов и кашированных витрин.
- Требуется scale‑to‑zero: среда разработки, демонстрационные стенды, ночные простои, снижение TCO за счёт «усыпления» вычислений.
- Приоритет — управляемость, SLA, мультизонность и 24×7 поддержка; меньший фокус на экстремальном single‑node throughput.
Сопоставление по ключевым осям
| Ось сравнения | OrioleDB | Neon |
|---|---|---|
| Архитектура | Новый TAM, UNDO‑MVCC, локальный кеш на squizzled pointers, строковый WAL | Стандартный Heap в compute; WAL → Safekeepers; страницы из Page servers; слои в объектном хранилище |
| CPU‑масштабирование | Снятие узких мест внутри узла; хорош для больших ВМ и смешанных R/W | Близко к vanilla Postgres на одной compute; компенсируется множеством read‑реплик |
| IO‑масштабирование | Copy‑on‑write чекпойнты + строковый WAL = меньше IOPS, лучше локальность | Распределённое хранилище, масштабируемое практически без ограничений, но с сетевой задержкой |
| VACUUM и блоут | UNDO устраняет рутину VACUUM; минимизация блоута, слияние разрежённых страниц | Обычный VACUUM на primary compute; блоут управляется классическими практиками |
| Разделение compute/storage | Гибрид: локальный диск — кеш, холодные данные в S3 (экспериментально) | Жёсткое разделение: compute статичен, состояние в распределённом хранении |
| Ветвления и клоны | Возможны сценарии через S3/бэкапы, но не как базовая фича TAM | Моментальные ветви и клоны — ключевая фича |
| Scale‑to‑zero | Возможен в S3‑режиме без нагрузки (экспериментально) | Нативно поддерживается |
| Производственная зрелость | Публичная бета, не рекомендован для прода | GA: AWS (2024), Azure (2025); поддержка, SLA |
| Совместимость | Требует пропатченный PostgreSQL 17; апстрим в процессе ревью | Патч‑сет на compute; регулярный ребейз на мажоры |
Экономика и TCO: где «выигрывают деньги»
OrioleDB
Экономия складывается из нескольких элементов:
- Меньше IOPS на ту же нагрузку благодаря строковому WAL и COW‑чекпойнтам.
- Отсутствие периодического VACUUM в классическом виде — меньше «скрытых» окон деградации, меньше трудозатрат на тюнинг.
- Локальный NVMe эффективно отрабатывает и пиковые окна, и тёплую нагрузку, снижая потребность «разбрасывать» данные по сети.
Издержки/компромиссы:
- На момент написания — бетастатус и необходимость в пропатченном ядре Postgres.
- Менее выраженная «облачная» управляемость по сравнению с Neon; меньше автоматизации вокруг клонов, реплик и жизненного цикла вычислений.
Neon
Экономические преимущества приходят из:
- Scale‑to‑zero — отсутствие затрат на compute при простое.
- Мгновенные ветвления и клоны — существенная экономия времени команд разработки и QA.
- Read‑реплики «по кнопке» — гибкая реакция на пики чтений без сложной ручной оркестрации.
- Мульти‑AZ хранение — снижение рисков больших простоев (опосредованно — экономия на SRE‑инженерии).
Издержки/компромиссы:
- Сетевые задержки и «цена удалённого байта»; для некоторых высокочувствительных OLTP‑кейсов это может быть критично.
- Сохранение «природы Heap» с VACUUM и вниманием к блоуту, пусть и смягчённых сервисной архитектурой.
Разработка и DevEx: как меняется рабочий процесс
Neon: ветвления как первый класс
Наличие «веток» БД меняет подход к разработке фич: любая гипотеза может быть проверена на изолированной копии боевых данных, при этом клон создаётся мгновенно, а место занимает только разница. Это ускоряет CI/CD, миграции, эксперименты с планами запросов, тестирование регрессий.
OrioleDB: предсказуемая латентность как актив
Разработчики приложений чувствительны к хвостам задержек. Если под капотом OrioleDB позволяет держать P95–P99 на коротком «поводке» даже во время пиков, это переводится в стабильность SLIs и меньше «микродёрганий» на стороне клиента. В итоге растёт уверенность в том, что тюнинг запросов и индексов даст стабильный эффект, не скрытый сетевыми факторами.
Наблюдаемость, бэкапы и восстановление
В Neon бэкап — это, по сути, встроенный в архитектуру побочный эффект слоёв и исторических точек. Восстановление до точки времени (PITR) и создание временных окружений — штатные сценарии. В OrioleDB фокус на «эффективности на узле»; при этом в S3‑режиме поддерживается архивирование WAL, синхронизация на чекпойнтах и экономия на хранении холодных данных. Подходы разные, но цели понятны: в первом случае — гибкость окружений, во втором — сбережение IO и места без потери горячей производительности.
Совместимость, расширяемость и экосистема
Оба проекта сохраняют совместимость на уровне SQL/интерфейсов клиента: приложения «видят» Postgres. Разница — в сторидж‑слое и особенностях эксплуатации. Для расширений и инструментов в среднем совместимость хорошая, но:
- Для OrioleDB учитывайте требования к версии ядра Postgres и патчам. Если вы полагаетесь на экзотические расширения, проверяйте взаимодействие заранее.
- Для Neon, как управляемого сервиса с пропатченным compute, проверьте список поддерживаемых расширений и ограничения окружения.
Практические сценарии
Финтех/платежи (низкая латентность, высокий write‑rate)
OrioleDB уместен там, где важна максимальная предсказуемость задержек и контроль блоута при непрерывном потоке транзакций. Если большая машина с NVMe — базовый строительный блок, UNDO‑MVCC и строковый WAL снимут достаточный слой накладных расходов.
Продуктовые команды с интенсивным фича‑девом
Neon даёт «кнопку» для веток БД и лёгких окружений. Для команды, в которой десятки разработчиков параллельно трогают схему, миграции и экспериментальные планы, выгода в человеко‑часах может перекрывать всю разницу в латентности.
Стартап с переменной нагрузкой и ночным «сном»
Scale‑to‑zero в Neon экономит деньги без ручной конвейерной автоматики. В OrioleDB также возможно снижение затрат в S3‑режиме, но пока это экспериментальная область и не заменяет жёсткого разделения compute/storage.
OLAP/BI на репликах
Неоновые read‑реплики позволяют вынести аналитические запросы, не вмешиваясь в горячий контур записи. Если ключевой KPI — скорость построения отчётов при минимальном влиянии на primary, возможности Neon будут проще в использовании, чем ручная настройка потоков логической или физической репликации.
Безопасность и мульти‑арендность
Neon изначально проектировался как многоарендный сторидж с кросс‑AZ репликацией, шифрованием на покое и в полёте, и сервисной изоляцией. OrioleDB — это TAM и инженерия производительности на узле; многопользовательские сценарии здесь решаются как в обычном Postgres или в рамках платформ, которые добавляют многоарендность сверху. Если ваша стратегия — «DBaaS‑платформа как сервис со строгой изоляцией», Neon встанет ближе к исходным требованиям.
Миграции и развёртывание
Neon
Перенос существующих баз в Neon часто выглядит как миграция в управляемый сервис: подключение репликации или импорт слоёв, переключение DNS/эндпоинта, настройка политик окружающей среды. Вы платите сетевой ценой, но выигрываете во времени и автоматизации.
OrioleDB
Переход к OrioleDB — это миграция локального формата хранения: нужна сборка с патчами, перенос данных/рейтинг тестов, валидация расширений. Награда — рост эффективности на узле, исчезновение рутины VACUUM и уменьшение блоута.
Риск‑профиль и зрелость
Если вы оперируете миссион‑критикал системой и цените «консервативность», управляемый сервис GA‑уровня с SLA, как Neon, выглядит безопаснее. Если вы готовы инвестировать в новый TAM ради выигрыша в предсказуемости и IO, и при этом прод аккуратно планируете на горизонте, OrioleDB даст вам технологическое преимущество, когда он достигнет GA. На сегодня для OrioleDB разумно рассматривать поэтапные пилоты и нагрузочные тесты в стейджинге.
Частые вопросы
Можно ли совместить преимущества OrioleDB и Neon?
Частично. Проекты идут разными путями. OrioleDB экспериментирует с S3‑режимом, но это не жёсткий split, как у Neon. Neon не заменяет Heap на TAM и не решает блоут через UNDO; он компенсирует это эксплуатационными фичами и эластичностью.
Что важнее: UNDO‑MVCC или мгновенные ветки?
Зависит от контекста. Для низкой латентности и write‑heavy — UNDO и строковый WAL (OrioleDB). Для скорости командной разработки, множества окружений и DevOps‑гибкости — ветвления и управляемый сторидж (Neon).
Как выбрать, если у нас смешанная нагрузка?
Измерять. Проведите POC на реальном трафике: профиль запросов, размер рабочих наборов, чувствительность к хвостам задержек, критичность клонов БД и read‑реплик. Как правило, выбор быстро кристаллизуется в пользу «производительности на узле» или «эксплуатационной пластичности».
Бенчмарки и измерения: на что смотреть
- Latency P95/P99 на смешанной R/W‑нагрузке с периодическими пиками чекпойнтов.
- IOPS и объём WAL на единицу полезной работы (вставки/апдейты малого и среднего размера).
- Поведение при «сдвиге» рабочих наборов из горячих в тёплые/холодные данные (локальный кеш vs сетевое чтение страниц).
- Стоимость владения при жизненном цикле окружений (ветки/клоны, read‑реплики, scale‑to‑zero для дев/стейдж).
- Надёжность и время восстановления при отказах AZ/узлов, сложность runbook‑ов.
Роадмап и ожидания на 2026 год
Оба проекта движутся быстро. Из того, что стоит «держать в поле зрения»:
- OrioleDB может довести S3‑режим до GA и расширить сценарии многорепличного подключения к одному объектному хранилищу. По мере захода патчей в апстрим PostgreSQL упростится внедрение.
- Neon будет наращивать зрелость self‑hosted сценариев и расширять поддержку облаков/регионов, углублять интеграцию с экосистемой и совершенствовать планировщики compute‑жизненного цикла.
Резюме: коротко о главном
- OrioleDB — это «Postgres как двигатель эффективности на одном узле»: UNDO‑MVCC, строковый WAL и COW‑чекпойнты дают высокую производительность и стабильную латентность, сводя VACUUM к минимуму. Экспериментальный S3‑режим добавляет экономию на холодном хранении без отказа от скорости локального диска.
- Neon — это «Postgres как сервис для эластичных окружений»: разнесённые compute/storage, мгновенные ветви, read‑реплики «по кнопке», scale‑to‑zero и мульти‑AZ хранилище с GA‑поддержкой и SLA.
Если вам важнее всего raw‑throughput и предсказуемость задержек — смотрите в сторону OrioleDB. Если вы живёте в мире активной разработки, множества окружений, динамики реплик и e2e‑управляемости — ваш выбор, скорее всего, Neon. И да, Postgres в 2026‑м действительно будет выглядеть иначе — благодаря таким проектам, как OrioleDB и Neon.
Чек‑лист выбора
- Нагрузка: write‑heavy/latency‑sensitive → OrioleDB; dev‑ветки/read‑replicas/scale‑to‑zero → Neon.
- Инфраструктура: большие ВМ и быстрый NVMe → OrioleDB; распределённое облако и мульти‑AZ → Neon.
- Операции: минимизация VACUUM‑рутины → OrioleDB; SLA/24×7/ветвления/реплики → Neon.
- Зрелость: готовность к бете и пилотам → OrioleDB; прод прямо сейчас → Neon.
