строк, 120 связанных таблиц и совпавшая контрольная сумма
Проверено, а не смоделировано
100 млн строк.
1,83 GiB на диске.
На зафиксированном торговом наборе RadixDB оказался в 8,21 раза компактнее PostgreSQL 18.3 и быстрее на массовых чтениях. Здесь же показано, где PostgreSQL остаётся быстрее.
1 964 220 021 байт логического объёма RadixDB
меньше одной базы на том же наборе, без PG cluster и WAL
нарушений в 2 100 проверках инвариантов
Текущие исходники сохраняют контракт 100M.
Каноническая проверка сохранила все 100 000 000 строк и checksum 100000000:49734600639880 после обновлений сервера, security, Application SDK и reliability.
11 870,421 ms measured run
Cold database selection занял 523,413 ms. Peak RSS составил 565,97 MiB, final RSS 343,04 MiB, allocated database size 1,83 GiB; ошибок storage и resources нет.
Protocol 18, TLS и schema-bound сервисы
Database-scoped authentication, типизированные protocol errors, Application SDK codegen, catalog 6.2, подпрограммы, ACL и trusted native extensions объединены одним документированным контрактом.
Компактнее на диске. Быстрее на больших чтениях.
RadixDB и PostgreSQL 18.3 получили один набор и одинаковую cardinality запросов на AMD Ryzen 9 7950X. RadixDB — медиана трёх run-level medians; PostgreSQL — сохранённый fresh baseline того же стенда.
Сканы, проекции, агрегации и 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.
100M NVMe verify: median peak RSS 522 MiB, final RSS 280 MiB. Файловый кэш ОС в эти цифры RSS не входит.
Слабое железо. Деградировавший диск. Завершённый recovery oracle.
Это тест надёжности, а не latency SLA: RadixDB прошёл лестницу до 256 клиентов, штатное и SIGKILL-переоткрытие, checkpoint, snapshot, restore и сравнение digest.
Ядро выполнило hard reset SATA link и retry flush. RadixDB восстановил progress; финальные snapshot, restore, invariants и digest прошли без corruption.
По фактической записи владельца PostgreSQL 18.3 остановился при seed 100M; ручной повтор на PostgreSQL 17 также не дошёл до benchmark-фазы. Более старые версии были недоступны из-за требований libc. Поэтому вымышленные latency для Celeron/HDD не публикуются.
Не одна цифра, а связанная архитектура.
Результат складывается из storage path, транзакционной модели, индексов, recovery и контролируемых границ расширения.
Гибридный row + column слой
Изменяемые версии строк для транзакций и неизменяемые сжатые сегменты для массового чтения.
MVCC, WAL и savepoints
READ COMMITTED и SNAPSHOT, атомарность statement, checkpoint и проверяемый reopen.
Навигация по внешним ключам
Read-only пути вида order.customer_id.group_id.title без ручного JOIN-шума.
B-tree, HASH, BITMAP и HNSW
Составные, уникальные, частичные, ordered, vector и extension-defined access paths.
Stable C ABI 1.0
Bounded external types, scalar и batch functions, operators и planner-aware index classes.
Embedded или authenticated server
Прямой Rust API либо protocol 18 поверх TLS 1.3 с database-scoped authentication.
Сгенерированные контракты схемы
Типизированные таблицы и процедуры, fingerprints, deadlines, cancellation, bounded results и явная обработка исхода.
Логика рядом с данными
Функции, процедуры, транзакционные триггеры, durable jobs, ACL и invoker/definer authority.
100M comparison относится к зафиксированным revisions, набору и NVMe-стенду. HDD soak доказывает наблюдавшийся correctness/recovery path, но не является SLA и не гарантирует сохранность при окончательной потере устройства или ложном подтверждении flush.
