What is ImmuDB, and when should you use it? A technical and practical overview

AWS has announced that it will be discontinuing its Quantum Ledger Database (QLDB) service in July 2025, prompting users to seek alternatives. The proposed PostgreSQL-based solutions cannot be considered true QLDB alternatives, as they do not provide the same level of low-level immutability. In contrast, Immutable Databases offer guarantees of data integrity and unalterability. For QLDB users, three open-source alternatives are currently recommended: ImmuDB, TerminusDB, and Dolt. This article provides a detailed overview of what ImmuDB is, when it makes sense to use it, and what other options are available.

What is ImmuDB, and how does it differ from traditional databases?

ImmuDB is an open-source database that stands out from conventional solutions by guaranteeing the immutability of stored data. While some existing databases offer add-on tools that enable data change tracking, the team at Codenotary approached the issue from a fundamentally different perspective. Their goal was to develop a database that ensures data immutability at its core, rather than relying on external components or workarounds.

According to Codenotary’s official publication, the key motivation behind creating the system was the need to address cybersecurity and data integrity. This naturally raises the question: what exactly does immutability mean, and how is it implemented in practice? In reality, the concept is more nuanced - better described by the term tamper-proof database solutions, which more accurately reflects the assurance of data integrity. Rather than offering absolute immutability or non-deletability, ImmuDB tracks every modification and verifies the integrity of that history using a data structure known as a Merkle tree database.

Merkle trees are binary trees where the leaves represent the hashed values of a dataset, and the inner nodes are hashes of their respective child nodes. Essentially, this creates a chain of hashes from each leaf up to the root. If the hash function used is cryptographically secure - meaning it is computationally infeasible to reverse or predict - then any change to a leaf node would alter the parent hash, and ultimately the root hash, exposing any unauthorized modification.

In the case of ImmuDB, this means that whenever a new entry is added - effectively a new leaf in the tree - the root hash remains valid only if all previous entries are unchanged. If someone attempts to alter or remove data without authorization, the updated hash structure will no longer match, and the system will detect the inconsistency.

In the field of cybersecurity, one often encounters a seemingly counterintuitive argument: open-source solutions can, in many cases, be more secure. The reasoning is that their inner workings are not only visible to potential attackers, but also to those with a vested interest in maintaining and improving the system’s security. The team behind ImmuDB adopted this very approach: written in Go, ImmuDB is a fully open-source project, publicly available on GitHub under the Apache 2.0 license.

Use cases for ImmuDB

The primary purpose of ImmuDB is to preserve the authenticity and integrity of data stored in a database. Similar goals are pursued by Blockchain-based databases, which also enable tracking changes to data over time. However, the two technologies can be considered inverses of each other in many respects. Blockchain solutions are best suited for scenarios where the parties involved in the business logic do not trust each other, and there is a need for decentralized consensus over relatively low-complexity data structures.

In contrast, the approach embodied by ImmuDB relies on a centralized, tamper-proof relational database model.

In the case of more conventional, "plain" databases, such functionality is not inherently provided by the database itself, but rather implemented through additional tools and extensions. These, in certain situations, can be bypassed - making the protection of data potentially vulnerable.

“Locks keep honest people honest.”

When to choose ImmuDB?

ImmuDB is primarily recommended in scenarios where data integrity, traceability of changes, and overall security are critical requirements - especially if higher efficiency than Blockchain-based systems is desired, but the benefits of a fully distributed architecture are not essential. According to the official ImmuDB website, several well-known companies already use the system in various capacities.

Despite its young age and the resulting challenges - such as limited compatibility and lack of documentation -, ImmuDB can still be an attractive option for startups looking to build their application around an infrastructure where immutability is a fundamental requirement. In such cases, ImmuDB’s speed and relatively easy development process can offer a significant advantage during the early stages of a company’s growth.

Using ImmuDB with different programming languages

ImmuDB is fundamentally a key–value pair database, which differs from the widely adopted relational database solutions. The core principle of a key-value store is that each piece of stored data is accessible via a unique key. However, this hasn’t stopped the developers from building an SQL abstraction layer on top of the system, allowing ImmuDB to emulate a relational database. While this use case is still limited compared to more mature relational database engines, it does provide essential functionality - within the boundaries of its immutability model.

Since ImmuDB is written in Go, the strongest native support is available for that language. In addition, several open-source client libraries exist for other popular languages such as Python, Java, .NET, and Node.js. For instance, when evaluating an ImmuDB Python example, developers should be aware that some features may not be fully implemented in the client library. These implementations vary, as not all of them offer the same feature set. Therefore, when choosing a programming language, it is essential to consult the specific documentation and limitations associated with that integration.