строк, 120 связанных таблиц и совпавшая контрольная сумма
Проверено, а не смоделировано
100 млн строк.
1,83 GiB на диске.
На зафиксированном торговом наборе RadixDB оказался в 8,21 раза компактнее PostgreSQL 18.3 и быстрее на массовых чтениях. Здесь же показано, где PostgreSQL остаётся быстрее.
1 964 220 021 байт логического объёма RadixDB
меньше одной базы на том же наборе, без PG cluster и WAL
нарушений в 2 100 проверках инвариантов
100M · NVMe · Btrfs
Компактнее на диске. Быстрее на больших чтениях.
RadixDB и PostgreSQL 18.3 получили один набор и одинаковую cardinality запросов на AMD Ryzen 9 7950X. RadixDB — медиана трёх run-level medians; PostgreSQL — сохранённый fresh baseline того же стенда.
МетрикаRadixDBPostgreSQL 18.3Результат
Логический объём базы1,964 GB16,127 GB8,21× компактнее
Полное сканирование100,299 ms246,457 ms2,46× быстрее
Выбранные столбцы23,189 ms84,456 ms3,64× быстрее
GROUP BY + HAVING9,907 ms24,948 ms2,52× быстрее
Сканы, проекции, агрегации и footprint
Гибридный row/column path особенно заметен там, где запрос читает большой объём данных или узкий набор столбцов.
Lookup, JOIN и write lifecycle
В этом срезе PG быстрее в точечном поиске в 2,07×, диапазоне в 1,77×, JOIN в 1,65× и UPDATE rollback в 3,93×. COPY был быстрее в 4,25×, но выполнялся с synchronous_commit=off.
Управляемая резидентность
Часть базы — или вся generation — может быть прогрета в RAM.
Уровни page_cache_level от 1 до 10 запрашивают примерно 10–100% текущей immutable generation. Для базы 100M размером 1,83 GiB полный прогрев реалистичен на выделенном хосте с достаточным запасом памяти.
Это файловый кэш ОС, а не heap RadixDB: страницы не закреплены и могут быть вытеснены. Перед level 10 учитываются доступная память, reserve и page_cache_max_bytes.
01около 10% generation для осторожного старта
05около 50% для горячей рабочей части
10до 100% generation при достаточном safe budget
100M NVMe verify: median peak RSS 522 MiB, final RSS 280 MiB. Файловый кэш ОС в эти цифры RSS не входит.
6 часов · 100M · constrained host
Слабое железо. Деградировавший диск. Завершённый recovery oracle.
Это тест надёжности, а не latency SLA: RadixDB прошёл лестницу до 256 клиентов, штатное и SIGKILL-переоткрытие, checkpoint, snapshot, restore и сравнение digest.
2 351 035операций
98 668зафиксированных транзакций
1 010,9 MiBpeak server RSS
196,8 MiBfinal server RSS
Ядро выполнило hard reset SATA link и retry flush. RadixDB восстановил progress; финальные snapshot, restore, invariants и digest прошли без corruption.
По фактической записи владельца отдельная попытка PostgreSQL 17 остановилась при seed 100M. Поэтому для Celeron/HDD не публикуются вымышленные query latency; сравнение выше относится к принятому NVMe baseline.
Ключевые возможности
Не одна цифра, а связанная архитектура.
Результат складывается из storage path, транзакционной модели, индексов, recovery и контролируемых границ расширения.
Гибридный row + column слой
Изменяемые версии строк для транзакций и неизменяемые сжатые сегменты для массового чтения.
MVCC, WAL и savepoints
READ COMMITTED и SNAPSHOT, атомарность statement, checkpoint и проверяемый reopen.
Навигация по внешним ключам
Read-only пути вида order.customer_id.group_id.title без ручного JOIN-шума.
BTREE, HASH и BITMAP
Составные и частичные индексы, статистика и выбор физического пути исполнения.
Версионированные native packages
Внешние типы, функции, операторы и operator classes через проверяемый plugin ABI.
Embedded и server mode
Прямой Rust API либо отдельный radixdb-server с типизированным TCP-клиентом и ORM facade.
Граница утверждений
100M comparison относится к зафиксированным revisions, набору и NVMe-стенду. HDD soak доказывает наблюдавшийся correctness/recovery path, но не является SLA и не гарантирует сохранность при окончательной потере устройства или ложном подтверждении flush.