В современном мире баз данных, где объемы информации растут экспоненциально, а требования к скорости и надежности становятся все строже, появляется все больше новых технологий, призванных улучшить возможности популярных систем управления базами данных. Среди таких инноваций особое внимание заслуживают OrioleDB и Neon — два проекта, нацеленных на перестройку и оптимизацию работы с PostgreSQL. Несмотря на кажущиеся внешние сходства и обещания стать «следующим поколением PostgreSQL», эти проекты принципиально отличаются по архитектуре, подходам к обработке данных и масштабируемости. Понимание этих отличий важно как для системных администраторов, так и для разработчиков, планирующих строить инфраструктуру на базе PostgreSQL в ближайшем будущем. OrioleDB представляет собой расширение для PostgreSQL, реализующее новую методику доступа к таблицам, заменяющую традиционное хранение в Heap.
Основой OrioleDB является MVCC (многоверсионный контроль конкуренции) на базе UNDO-логов, благодаря чему сокращается распространенная проблема с раздутием базы в PostgreSQL. Технология копирования при записи (copy-on-write) используется для оптимизации контрольных точек (checkpoints), что снижает нагрузку на диск и уменьшает объем журналирования транзакций (WAL) на уровне строк. Также OrioleDB внедряет уникальный кэш-слой в общей памяти, использующий оптимизированные индексы — squizzled pointers — что позволяет значительно повышать читаемость и масштабируемость при высоком уровне нагрузки и большом количестве транзакций. В отличие от OrioleDB, Neon сохраняет стандартный метод доступа к таблицам (Heap), но кардинально изменяет уровень хранения данных. В его архитектуре используется разделение на вычислительный и хранилищный слои, где журнал транзакций фиксируется с помощью специализированных сервисов Safekeeper, а данные считываются с серверов страниц, которые опираются на распределенное объектное хранилище.
Такой подход позволяет мгновенно создавать новые ветвления базы данных и масштабироваться, отключая вычислительные узлы в периоды отсутствия нагрузки, что идеально вписывается в концепцию облачных решений и масштабируемости до нуля. Если рассматривать масштабируемость по процессору, OrioleDB выделяется за счет устранения традиционных узких мест, связанных с менеджером буферов PostgreSQL и писателем WAL. Применение собственной структуры кэширования с помощью squizzled pointers и пооперационного WAL дает возможность эффективно обрабатывать интенсивные операции чтения и записи даже на мощных виртуальных машинах с большим количеством ядер. В то время как масштабируемость вычислительного слоя в Neon сопоставима со стандартным PostgreSQL, ключевая особенность заключается в поддержке мгновенного подключения большого количества вычислительных узлов в режиме только для чтения, что расширяет возможности по горизонтальному масштабированию. При обсуждении ввода-вывода OrioleDB выигрывает за счет реализации копирования при записи во время контрольных точек, что улучшает локальность операций записи и снижает общую нагрузку на диск.
Помимо этого, мелкозернистый WAL в OrioleDB экономит операции записи ввиду своего компактного объема. Neon рассчитан на работу с распределенным сетевым хранилищем, которое теоретически может масштабироваться бесконечно, однако сетевые задержки могут существенно влиять на скорость доступа по сравнению с быстрыми локальными NVMe-накопителями. Особое внимание уделяется и проблемам вакуума и раздувания данных. OrioleDB выводит уникальный механизм на основе блоковых и строковых UNDO-логов, что фактически устраняет необходимость в рутинных операциях VACUUM, а механизм слияния разреженных страниц помогает предотвращать и минимизировать раздувание базы. Neon, напротив, использует стандартный VACUUM PostgreSQL на главном вычислительном узле, рассчитывая на смягчение проблем за счет масштабируемого многоарендного хранилища и распределения нагрузки.
Одной из ключевых вещей в архитектуре Neon является с самого начала запланированное жесткое разделение хранения и вычислительного слоя. Вычислительные узлы являются по сути безсостояниевыми, за исключением общей памяти, что позволяет им очень быстро запускаться, приостанавливаться, клониться и удаляться. Вся долговременная информация хранится на стороне Safekeepers и серверов страниц, использующих S3-совместимое объектное хранилище с многоуровневым кэшированием на SSD. Это обеспечивает такие возможности, как мгновенное ветвление, масштабирование вниз почти до нуля и создание реплик чтения одним кликом. Хранилище распределено по зонам доступности и рассчитано на высокую отказоустойчивость.
В свою очередь, OrioleDB может работать в экспериментальном режиме с распределенным объектным хранением S3, где локальный диск действует как кэш для горячих данных, с возможностью эвикции холодных сегментов, а WAL-логи архивируются в S3. Однако, в отличие от Neon, для полноценной работы ему все еще необходим локальный диск и возможности для синхронизации между репликами находятся в стадии разработки. Что касается готовности к промышленному использованию, Neon уже доступен в статусе General Availability с августа 2024 года на AWS и с мая 2025 года на Azure с нативной интеграцией, при этом предоставляется полноценная поддержка с SLA и 24/7 сервисом для бизнес-пользователей. OrioleDB, напротив, находится в публичной бета-версии, требующей сборки с патчами PostgreSQL 17, они находятся на стадии рассмотрения и еще не приняты в основной репозиторий. Поддержка осуществляется сообществом, а коммерческие проекты с OrioleDB пока находятся в экспериментальной стадии.
Подводя итог, можно сказать, что OrioleDB ориентирован на тех, кто заинтересован в максимальной производительности на одиночном узле, предсказуемости задержек и минимизации проблем с обслуживанием базы данных, таких как VACUUM и блоонг. Его уникальные технические решения максимально используют внутренние ресурсы серверного оборудования с эффективным управлением памятью и вводом-выводом. Экспериментальный режим с S3-совместимым хранилищем обещает расширить возможности по снижению стоимости хранения без существенных потерь в скорости обработки горячих данных. Neon же выделяется как решение для компаний и проектов, которым важна автоматизация операций, гибкость и масштабируемость, а также возможности быстрого развертывания множества вычислительных узлов для чтения и клонирования данных. Его архитектура ориентирована на облачные среды с эластичным ресурсопотреблением, упрощая эксплуатацию и администрирование.
В 2026 году можно ожидать, что обе технологии еще активнее будут интегрироваться и дополнять возможности PostgreSQL, трансформируя привычные процессы эксплуатации баз данных и расширяя горизонты для пользователей и разработчиков. Выбор между OrioleDB и Neon определяется конкретными бизнес-задачами, требованиями к инфраструктуре и приоритетами в производительности и масштабируемости.
