Release notes We’re pleased to introduce version 1.4 of immudb, which comes with two major features: FIPS-Compliant ...
Release notes
We’re pleased to introduce version 1.4 of immudb, which comes with two major features: FIPS-Compliant Builds and Synchronous Replication. And, of course, we’ve fixed bugs and made other improvements.
You can find the new release here for all major platforms:
https://github.com/codenotary/immudb/releases/tag/v1.4.0
Regarding SDKs, please make sure to check the compatibility list:
https://docs.immudb.io/master/getstarted/jumpstart.html
FIPS-Compliant Builds
Starting with v1.4.0, immudb can be compiled using the go-boringcrypto fork of the Go compiler, which uses the FIPS 140-2 compliant boringssl library. We now also officially provide FIPS-compliant binaries and Docker images.
What is it? The FIPS 140-2 standard prescribes the design and security requirements for cryptographic modules that may be approved for use by the United States government. FIPS-140 is a collection of computer security standards set by the National Institute of Standards and Technology (NIST) for the United States government. FIPS 140–2 defines the critical security parameters vendors must use for encryption implementations sold to the U.S government.
Detailed information about FIPS-compliant immudb build can be found in immudb’s source code repository.
Synchronous Replication
Synchronous replication improves the reliability of data replicated across the immudb nodes in a cluster. When an immudb cluster uses synchronous replication, the primary node waits for sufficient transaction confirmations from replicas before it considers the transaction fully committed and durably stored by multiple nodes. This feature increases data durability by allowing any single node in an immudb cluster—including the primary node—to be lost without causing the database state tracked by the nodes and clients to diverge.
Prior to version 1.4, immudb only supports asynchronous replication. When a cluster is configured to use asynchronous replication, replica nodes can lag behind the primary node, and any given transaction committed on the primary node isn’t guaranteed to be replicated to other nodes within a reasonable time period. Thus, transactions committed to a primary node that has not been replicated can be lost if the primary node is irrecoverably lost. When this occurs, the state of the surviving nodes may diverge from the state computed by the immudb client, because the new primary node elected from the remaining replicas could be missing the most recent commits tracked by the clients.
To get more information about synchronous replication please refer to the documentation on docs.immudb.io.
Replication performance
Due to additional synchronization between nodes, commit throughput with synchronous replication will naturally be slower compared to a single-node cluster. The performance difference will depend on various factors such as the speed of disks, network latency, and the number of followers.
In this release we also worked on improvements to the replication mechanism itself, achieving 17 to 20 times larger TX/s replication throughput than what was available in the 1.3.2 release.
SDK Updates
This release also comes with significant updates to immudb SDKs. We’ve brought brand new .Net SDK; added inline documentation to Go SDK; added inline documentation and increased functionality of Python SDK and Java SDK; and made significant updates to the node.js SDK 1.
You can find the full change log and the release download here: