rows, 120 related tables, and a matching checksum
Measured, not modeled
100 million rows.
1.83 GiB on disk.
On a frozen trading dataset, RadixDB was 8.21 times smaller than PostgreSQL 18.3 and faster on large reads. This page also shows where PostgreSQL remains faster.
1,964,220,021 logical bytes for RadixDB
smaller single database on the same dataset, excluding the PG cluster and WAL
violations across 2,100 invariant checks
100M · NVMe · Btrfs
Smaller on disk. Faster on large reads.
RadixDB and PostgreSQL 18.3 used the same dataset and query cardinalities on an AMD Ryzen 9 7950X. RadixDB is the median of three run-level medians; PostgreSQL is the preserved fresh baseline from the same host.
MetricRadixDBPostgreSQL 18.3Outcome
Logical database size1.964 GB16.127 GB8.21× smaller
Full scan100.299 ms246.457 ms2.46× faster
Projected columns23.189 ms84.456 ms3.64× faster
GROUP BY + HAVING9.907 ms24.948 ms2.52× faster
Scans, projections, aggregates, and footprint
The hybrid row/column path is most visible when a query reads a large data range or a narrow set of columns.
Lookup, JOIN, and write lifecycle
In this slice PG is 2.07× faster on point lookup, 1.77× on range lookup, 1.65× on JOIN, and 3.93× on UPDATE rollback. COPY is 4.25× faster, with synchronous_commit=off.
Controlled residency
A working fraction — or the full generation — can be warmed into RAM.
page_cache_level values 1 through 10 request roughly 10–100% of the current immutable generation. For the 1.83 GiB 100M database, full warmup is practical on a dedicated host with sufficient memory headroom.
This is operating-system page cache, not RadixDB heap: pages are not pinned and may be evicted. Level 10 remains bounded by available memory, reserve, and page_cache_max_bytes.
01about 10% of the generation for a cautious start
05about 50% for a hot working set
10up to 100% when the safe budget permits it
100M NVMe verify: median peak RSS 522 MiB, final RSS 280 MiB. OS page cache is not included in process RSS.
6 hours · 100M · constrained host
Weak hardware. Degraded disk. A completed recovery oracle.
This is reliability evidence, not a latency SLA: RadixDB completed the ladder to 256 clients, graceful and SIGKILL reopen, checkpoint, snapshot, restore, and digest comparison.
2,351,035operations
98,668committed transactions
1,010.9 MiBpeak server RSS
196.8 MiBfinal server RSS
The kernel hard-reset the SATA link and retried the flush. RadixDB recovered progress; final snapshot, restore, invariants, and digest completed without corruption.
According to the test-owner record, a separate PostgreSQL 17 attempt stopped while seeding 100M. No synthetic query latency is published for Celeron/HDD; the comparison above belongs to the accepted NVMe baseline.
Key capabilities
Not one number, but a connected architecture.
The result comes from the storage path, transaction model, indexes, recovery, and controlled extension boundaries working together.
Hybrid row + column layer
Mutable row versions for transactions and immutable compressed segments for large reads.
MVCC, WAL, and savepoints
READ COMMITTED and SNAPSHOT, statement atomicity, checkpoints, and verified reopen.
Navigable foreign keys
Read-only paths such as order.customer_id.group_id.title without manual JOIN noise.
BTREE, HASH, and BITMAP
Composite and partial indexes, statistics, and physical execution-path selection.
Versioned native packages
External types, functions, operators, and operator classes through a validated plugin ABI.
Embedded and server modes
Direct Rust API or standalone radixdb-server with a typed TCP client and ORM facade.
Claim boundary
The 100M comparison belongs to frozen revisions, one dataset, and the NVMe host. The HDD soak proves the observed correctness and recovery path; it is not an SLA and does not guarantee survival of permanent device loss or false flush acknowledgement.