Выбор RadixDB

RadixDB, SQLite, DuckDB и PostgreSQL решают пересекающиеся, но разные задачи. Эта глава помогает выбрать архитектуру, а не выстраивает универсальный рейтинг. Значение «Да» в одной строке не означает одинаковую семантику, эксплуатационную зрелость или быстродействие.

Столбец RadixDB описывает версию 1.2.25. Остальные столбцы обобщают официальную документацию продуктов, проверенную 15 сентября 2026 года. Используйте ссылки на источники в конце главы: эти проекты продолжают развиваться.

Сравнение возможностей

Возможность	RadixDB 1.2.25	SQLite	DuckDB	PostgreSQL
Встраиваемая работа	Да. Rust API открывает базу в памяти или файлах внутри процесса приложения.	Да. Основная модель является in-process, self-contained и serverless.	Да. In-process является основной моделью; доступны API для нескольких языков.	В ядре нет in-process режима. Приложения подключаются к серверу.
Отдельный сетевой сервер	Да. Тот же движок работает через собственный TCP-протокол.	Встроенного сервера нет. Приложения напрямую читают и изменяют файл базы.	Это не традиционная основная модель. В проверенной документации официальный remote protocol Quack находится в beta.	Да. Client/server является основной архитектурой.
Транзакции и конкурентность	Изменение строк под MVCC с `READ COMMITTED` и `SNAPSHOT`; `SERIALIZABLE` не поддерживается.	ACID и snapshot-поведение с конкурентными читателями, но сериализованной записью в файл базы.	ACID с bulk-optimized MVCC и optimistic concurrent writes внутри одного writer process.	Многосессионный MVCC со стандартными уровнями изоляции, включая serializable isolation.
Физическая организация данных	Гибридная: изменяемые MVCC-строки и неизменяемые сжатые блоки колонок в row groups.	Записи строк в компактном файле базы с B-tree организацией.	Колонночное хранение и векторизованное выполнение для аналитики.	В ядре используется строчно-ориентированное heap storage; extensions могут добавлять другие подходы.
Основной класс нагрузки	Смешанные транзакционные изменения и аналитическое сканирование длительно живущих прикладных данных.	Локальное состояние приложения, устройства и переносимые файлы приложений.	In-process OLAP, bulk operations и анализ файлов, data frames и lakehouse data.	Универсальные многопользовательские серверные нагрузки с широкими OLTP, аналитическими и эксплуатационными возможностями.
Functions, procedures и triggers	RadixDB PL предоставляет хранимые функции, процедуры, триггеры и задания в ограниченных runtime contracts.	Доступны triggers и SQL functions, определённые host-приложением; отдельной подсистемы stored procedures нет.	Доступны macros, SQL functions и extension functions; это не традиционная серверная модель stored procedures.	Stored functions, procedures и triggers на PL/pgSQL и других процедурных языках.
Native extensions	Да. Доверенные оператором in-process packages используют stable C ABI, Rust SDK и точный allowlist.	Да. Loadable extensions добавляют functions, collations, virtual tables и другие возможности.	Да. Core и community extensions добавляют types, functions, formats и protocols.	Да. Extension framework добавляет types, functions, operators, access methods и native code.
PostgreSQL wire protocol	Нет. RadixDB использует собственный версионируемый протокол и клиент.	Нет.	Нет.	Да.
Встроенные replication, failover и PITR	Нет. В 1.2.25 есть snapshots и restore, но не заявлены HA, replication, automatic failover или PITR к произвольной позиции WAL.	Нет встроенной серверной подсистемы HA; replication требует прикладного или стороннего слоя.	Не является основной встроенной моделью HA сервера базы данных.	Да. Physical и logical replication, standbys, компоненты failover и PITR являются развитыми серверными возможностями.
Стадия публичной экосистемы	Первый упакованный публичный выпуск, Rust-first клиенты и инструменты, намеренно узкая экосистема.	Чрезвычайно зрелая и широко распространённая экосистема с bindings и инструментами для множества платформ.	Зрелая аналитическая экосистема с широкой интеграцией языков и инструментов данных.	Чрезвычайно зрелая серверная экосистема с множеством драйверов, средств администрирования, hosting и extensions.

Эти строки сравнивают архитектуру продуктов, а не синтаксис SQL по отдельным конструкциям. Точные поддержанные и отклоняемые возможности RadixDB находятся в матрице SQL.

Где RadixDB особенно полезна

RadixDB рассчитана прежде всего на прикладные системы, в которых оперативные данные живут годами, постоянно изменяются и одновременно служат источником отчётов, сложных выборок и аналитики. Наиболее естественные области применения:

ERP, CRM, складские, учётные и производственные системы, где множество связанных сущностей сочетается с ежедневными изменениями, отчётами и агрегатами;
географические базы, каталоги и справочные системы со сложной схемой, большим числом повторяющихся значений и частыми переходами между связанными записями;
мониторинг, телеметрия и история событий, где новые данные активно обрабатываются, а накопленный массив требуется компактно хранить и быстро просматривать;
локальные, on-premise и edge-системы с ограниченными ресурсами, для которых важны сжатое хранение, небольшой расход памяти и автономная работа;
Rust-приложения, которым нужен единый движок для локального запуска внутри процесса и последующего перехода к многопользовательскому серверу;
специализированные отраслевые решения, где функции, триггеры и доверенные расширения позволяют разместить проверяемую предметную логику рядом с данными.

Главное преимущество RadixDB проявляется в смешанной нагрузке: небольшие транзакционные изменения соседствуют с регулярным чтением больших массивов. Гибридное хранение позволяет обслуживать оба сценария одной базой, не выделяя отдельное аналитическое хранилище на раннем этапе, а сжатие помогает удерживать большую часть рабочего набора в памяти.

Измерения показывают сильные и более медленные сценарии на конкретном оборудовании. Они помогают проверить соответствие своей нагрузке, но не заменяют испытание реальной прикладной схемы.

Где лучше выбрать другой движок

RadixDB не стремится заменить любую СУБД. Для следующих задач существуют более подходящие и зрелые решения:

для небольшого локального приложения, которое хранит настройки и простые записи в одном переносимом файле без сервера и аналитики, SQLite будет проще и компактнее;
для преимущественно аналитической обработки Parquet, data frames и данных в object storage, когда изменения выполняются крупными пакетами и нет постоянно работающей многопользовательской системы, лучше подходит DuckDB;
для существующего PostgreSQL-приложения, зависящего от его драйверов, ORM, расширений и средств администрирования, переход на RadixDB не даст совместимости без переработки приложения;
для критичной системы 24/7, которой уже сейчас необходимы встроенная репликация, автоматическое переключение, кластер высокой доступности и восстановление к произвольному моменту времени, следует выбрать PostgreSQL или другую зрелую серверную СУБД;
для глобально распределённой записи, горизонтального масштабирования и автоматического шардинга нужен специализированный распределённый движок;
для проектов, где обязательны многолетняя публичная история, сертифицированная поддержка, широкий выбор готовых интеграций и специалистов, экосистема RadixDB пока слишком молода.

Иными словами, RadixDB наиболее уместна не как универсальная замена зрелому серверу, а как компактное ядро прикладной системы со связанными данными и одновременной транзакционной и аналитической работой.

Источники и границы

Поведение RadixDB описано в главах «Что такое RadixDB?», «Транзакции», «Клиентские интерфейсы», «Разработка native extensions» и «Диагностика и устранение проблем».

Для остальных продуктов использована первичная документация:

SQLite: описание SQLite, serverless-архитектура и изоляция транзакций.
DuckDB: назначение DuckDB и конкурентность.
PostgreSQL: client/server architecture, MVCC, PL/pgSQL и extensibility.

Описания зрелости качественные. Результаты benchmarks намеренно не включены в таблицу возможностей: междвижковая производительность зависит от нагрузки и конфигурации.