RadixDB is a lightweight database built on a Radix tree structure. While initially implemented in Go, the database file format is platform-agnostic. This allows easy read and write from any programming language, without special bindings.
🏗️ RadixDB is currently in active development. We plan to announce its readiness for general availability when appropriate. Stay tuned for updates.
RadixDB is designed with a focus on portability and cross-platform, language-agnostic usage. When a developer constructs a Radix tree in their application, it's typically for a specific purpose. Therefore, the ability to persist the tree structure is valuable, as it allows applications to avoid rebuilding the tree on each restart. This is particularly beneficial when the tree's construction relies on external data sources that may not always be reliably available. RadixDB addresses this need by offering a straightforward mechanism to persist and reload Radix trees. Alternatively, RadixDB can be used exclusively for in-memory operations when persistence is not required.
The Go implementation of RadixDB employs a concurrency model based on the single-writer, multi-reader paradigm. This model allows multiple readers to access the database concurrently without locking, while write operations are limited to a single writer at a time to ensure data integrity. Other implementations of RadixDB might adopt different concurrency models to better suit specific performance needs or language constraints.
RadixDB employs a dual-representation persistence model. It maintains a complete in-memory representation of the Radix tree for fast operations, while also providing a platform-agnostic on-disk format for durability. When saving the database, RadixDB traverses the tree to compute its on-disk layout, ensuring data integrity and consistency. Future versions may implement techniques such as memory mapping to allow partial loading of the tree, while supporting the existing RadixDB file format.
RadixDB ensures data integrity using IEEE CRC32 checksums, which verify the database's integrity both during regular operations and while persisting data. These checksums detect potential corruption or tampering in the Radix tree structure by enforcing verification both in-memory and at the filesystem level. The checksums are calculated across all nodes of the Radix tree, providing comprehensive coverage. While this approach is robust for general data integrity, it does not provide cryptographic-level assurance against deliberate tampering.
Contributions of any kind are welcome. If you're submitting a PR, please follow Go's commit message structure.