RadixDB

Русский

Official website · Support

RadixDB is an open source SQL database written in Rust. It combines transactional row updates with compressed column-oriented storage, bringing a compact data footprint and analytical query capabilities to application databases.

RadixDB runs as a standalone TCP server or as an embedded Rust library. Its design focuses on reliable recovery, controlled memory use and efficient access to large, connected datasets.

Development of RadixDB is sponsored by Light Soft.

Documentation · Getting started · Release notes · Test results · Evidence archive

Performance and accessibility

Query performance

A comparative test on a Ryzen 9 7950X and NVMe storage measured these query latencies on a 100-million-row relational dataset:

RadixDB was approximately 2.5 to 3.6 times faster in these cases. PostgreSQL was faster in the same comparison for point/range lookup, the parent JOIN, bulk loading and index creation. Results are workload-specific, use recorded revisions and do not represent measurements of every subsequent commit. The full results and methodology include both strengths and slower cases.

Reliability under demanding conditions

Transactions, write-ahead logging, checksummed storage and verified physical snapshots provide the foundation for recovery. A six-hour endurance test used 100 million rows and up to 256 clients on a machine with 1.76 GiB RAM and a 5400 rpm hard drive.

During the run, a real SATA transport failure interrupted a disk flush. After the kernel reset the link and retried the operation, the engine resumed work. The test completed 2,351,035 operations and 2,100 invariant checks with no invariant failures; the restored snapshot matched the source logical digest. This demonstrates recovery from the observed transient failure, rather than permanent loss of the drive. The report also records temporary stalls and their recovery.

Low memory requirements

Large databases do not have to be loaded completely into process memory. In the same 100-million-row endurance test, peak server RSS was approximately 1,011 MiB and final RSS returned to 197 MiB.

For smaller deployments, the 20,000-row profile with 120 tables measured 23.4 MiB at clean reopen using the system allocator, or 54.2 MiB with the default mimalloc allocator. These are separate, measured workload profiles, with explicit worker and cache settings.

Rust foundation

A shared Rust implementation serves embedded applications and the TCP server, without requiring a managed runtime. Rust provides a foundation for porting the engine across processor architectures and operating systems. Linux x86-64 is the platform demonstrated by the results above; other targets require their own build, filesystem and recovery validation.

Applications can use the embedded radixdb library, the standalone radixdb-client TCP client and the radixdb-orm data-access layer.

Engine design and functionality

Hybrid storage for connected data

RadixDB combines mutable MVCC rows with immutable, compressed column blocks organized into row groups. This hybrid row/column design supports transactional changes while allowing scans to read the columns a query needs. Block statistics can eliminate irrelevant row groups before reading their payloads.

The design is useful for wide, related datasets with a mixture of updates, filtering and aggregation: asset inventories, telemetry and geographic attribute databases, for example. Geographic attributes can benefit from these access patterns; dedicated geometry types, spatial indexes and GIS functions are supplied separately by a native extension rather than implied by the storage layout.

Compact storage and configurable caching

Immutable data artifacts store column blocks with compression. In the September 2026 comparative test, the 100-million-row database occupied 1.96 GB of logical storage, compared with 16.13 GB for PostgreSQL: approximately 8.2 times smaller for that dataset.

Compression also makes more data fit into memory. RadixDB provides optional operating-system page-cache warmup. When the compressed database fits the available memory budget, most or all of its file data can remain cached, reducing repeated disk reads. Cache residency depends on available memory and workload; the operating system can evict pages.

The server exposes page_cache_level, page_cache_max_bytes and page_cache_memory_reserve. See configuration and memory boundaries.

Navigable references

RadixDB lets SQL follow declared foreign keys using a field path. Applications can express relationships directly, without repeating JOIN clauses for every related attribute:

CREATE TABLE departments (
    id INTEGER PRIMARY KEY,
    name TEXT NOT NULL
);

CREATE TABLE employees (
    id INTEGER PRIMARY KEY,
    name TEXT NOT NULL,
    department_id INTEGER REFERENCES departments(id)
);

SELECT e.name, e.department_id.name AS department
FROM employees AS e;

For valid foreign-key data, this returns the same values as a LEFT JOIN from employees to departments. A NULL department key produces a NULL department name. The key remains an ordinary scalar value in the employee row.

Paths can span several relationships, for example p.employee_id.department_id.name. Fields sharing a path reuse its canonical edges. The engine binds the relationships from schema metadata and executes one query plan, avoiding an application-side query for every row. Paths can participate in filters, grouping, sorting and aggregate expressions; EXPLAIN ANALYZE exposes their execution strategy.

Navigation is read-only. It follows single-column foreign keys to a primary key or UNIQUE NOT NULL target in the same database, with up to eight steps. Writes name their target table explicitly; reverse one-to-many traversal uses ordinary JOINs. See navigable references for integrity checks and supported query contexts.

Integrated ORM

RadixDB includes an ORM for building queries and working with records in Rust. It is integrated with both the embedded database API and the TCP client. ORM operations compile to ordinary SQL with typed parameters, so raw SQL and ORM queries can share the same connection, transaction and snapshot.

use radixdb_orm::{table, Expr, OrmBuilder, QueryBuilder};

let query = QueryBuilder::from_relation(table("employees"))
    .select([
        Expr::column("name"),
        Expr::navigation("employees", ["department_id", "name"]),
    ])
    .filter(Expr::column("department_id").eq(10))
    .limit(100);

let compiled = query.to_sql()?;

The example builds a query without opening a connection. Its filter value becomes a parameter rather than interpolated SQL. A connected application can execute the builder through the client, or use the embedded ORM execution API.

The ORM supports two complementary ways of working with data. Generated Rust models provide typed columns, key descriptors, references and change tracking. Dynamic entities use database schema descriptors at runtime, which is useful for administration tools and applications whose schemas vary. Schema descriptions can also be exported for offline model generation.

Queries cover joins, navigation, grouping, windows, CTEs and subqueries. DDL builders describe tables and constraints; record operations distinguish omitted values, NULL and assigned values. A versioned JSON representation and form descriptors support tools that inspect or construct queries and forms.

A Reference<T> stores a target key and supports explicit read navigation. Saving a record does not implicitly fetch or save an entire related object graph. Automatic schema migration is a separate concern. See the ORM guide and the runnable Rust example.

Trusted native extensions

RadixDB 1.2 provides a stable C ABI, a safe Rust SDK and deterministic package tooling for operator-trusted native extensions. An extension can add bounded scalar types, native scalar and batch functions, binary operators, B-tree/hash/bitmap operator classes and bounded planner support. The radixdb-spatial proving extension implements geometry values, predicates and Morton-key B-tree access entirely through this public boundary.

The database retains ownership of storage, WAL, MVCC, catalog publication, index pages, ACL and recovery. Native packages run in-process and are therefore trusted like the server binary; the startup loader accepts only complete, checksummed packages from exact absolute allowlist entries. Database bindings pin package version, fingerprint and codec identity.

This extension surface, together with functions, procedures and triggers, forms a practical base feature set for domain-specific database behavior. Applications can compose more specialized behavior from these mechanisms even when the corresponding syntax or operational workflow differs from PostgreSQL. See extension operation, the developer guide and the public Rust example.

SQL capabilities

• MVCC transactions, SQL DDL/DML, joins, subqueries and window functions.
• B-tree, hash, bitmap and HNSW indexes, including unique and partial indexes.
• UUID values, UUIDv7 generation and relational constraints.
• ROLLUP, CUBE, GROUPING SETS and GROUPING().
• Navigable references such as employee.department_id.name.
• Trusted native extensions with external scalar types, functions, operators and planner-aware index classes.

The SQL feature matrix describes RadixDB's own supported syntax and restrictions. Its wire protocol and SQL dialect are native to RadixDB; drop-in PostgreSQL compatibility is not a design goal.

PL/SQL: application logic in the database

The RadixDB 1.2 development line includes its own procedural SQL language. Functions, procedures and triggers keep validation, multi-step updates and business rules close to their data, within the same transaction as the changes they govern.

The accepted implementation includes typed variables and arguments, conditions, loops, cursors, exception handling, parameterized dynamic SQL, stored functions and atomic procedure calls through CALL. BEFORE/AFTER row and statement triggers use typed OLD and NEW records. Execution shares the SQL engine's transaction and bounded resource model; errors roll back the enclosing statement's changes, including trigger effects. Durable Job definitions, attempt records and the stock server's durable background scheduler are included. Job delivery is at-least-once; procedures can use the stable attempt idempotency key when duplicate effects matter.

This is RadixDB's own PL/SQL language, not an Oracle PL/SQL or PostgreSQL PL/pgSQL compatibility layer.

ACL: roles and access control

The RadixDB 1.2 development line includes database-enforced principals, roles and membership, object ownership, table and column access, and privileges such as SELECT, INSERT, UPDATE, DELETE and EXECUTE. Routines can execute with invoker or definer authority, with checks performed inside the engine. Grants and revocations are transactional catalog changes, and later execution observes the new authorization state.

Row-level security is not implemented. The stock TCP server authenticates catalog Principals with passwords and supports either ordinary TCP on a trusted network or direct TLS with certificate and server-name validation. Authorization then enforces database, schema, object and routine privileges for that Principal.

Getting started

Use the toolchain in rust-toolchain.toml:

cargo build --locked --release --bin radixdb-server --bin radixdb-password --bin radixdb-cli --bin radixdb-smoke-client --features cli
target/release/radixdb-cli -e "SELECT 1"

The CLI opens local databases. For a persistent database, use -d file:///path/to/database; for TCP connections, use the Rust client. See server installation, configuration and the RadixTrade tutorial.

Create a catalog Principal with a password for ordinary application access. For administrative access, configure an Argon2id verifier generated by radixdb-password; this requires the original password on every endpoint and disables passwordless root. If no verifier is configured, passwordless root remains available only as a recovery login on a plaintext loopback endpoint. See the authentication guide and security policy before exposing a connection.

Documentation and releases

• User documentation and Russian documentation.
• Rust client and ORM.
• Architecture and storage compatibility.
• Backup and maintenance.
• Release notes, contributing and community conduct.

RadixDB 1.1.0 was released on September 8, 2026 under the annotated tag v1.1.0. Use the release notes and storage compatibility contract when selecting a revision or planning an upgrade; later branch commits are not part of that release unless another tag says so.

License

RadixDB uses component-based licensing. The engine, server, and embedded engine are licensed under PolyForm Perimeter 1.0.1, while the client, ORM, wire protocol, and extension SDK components remain under Apache License 2.0.

See LICENSING.md for the authoritative component map, COMMERCIAL-LICENSING.md for competing-use permissions, CLA.md for contributions, and TRADEMARKS.md for branding rules. A Russian overview is available in LICENSING.ru.md.