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
CURRENT LINE · 1.2.25
Current source keeps the 100M contract.
The canonical verification preserved all 100,000,000 rows and checksum 100000000:49734600639880 after the server, security, Application SDK, and reliability changes.
11,870.421 ms measured run
Cold database selection took 523.413 ms. Peak RSS was 565.97 MiB, final RSS 343.04 MiB, and allocated database size 1.83 GiB with no storage or resource errors.
Protocol 18, TLS, and schema-bound services
Database-scoped authentication, typed protocol errors, Application SDK codegen, catalog 6.2, routines, ACL, and trusted native extensions now share one documented contract.
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, PostgreSQL 18.3 stopped while seeding 100M; a manual retry with PostgreSQL 17 also failed before the benchmark phase. Older versions were blocked by libc requirements. No synthetic Celeron/HDD latency is published.
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.
B-tree, HASH, BITMAP, and HNSW
Composite, unique, partial, ordered, vector, and extension-defined access paths.
Stable C ABI 1.0
Bounded external types, scalar and batch functions, operators, and planner-aware index classes.
Embedded or authenticated server
Direct Rust API or protocol 18 over TLS 1.3 with database-scoped authentication.
Generated schema contracts
Typed tables and procedures, fingerprints, deadlines, cancellation, bounded results, and explicit outcome handling.
Logic beside the data
Functions, procedures, transactional triggers, durable jobs, ACL, and invoker/definer authority.
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.