[Feat] Immudb 1.4 release notes

[byo]

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.

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.

A 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 have 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 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 [^*].

[^*]: Some SDKs updates will be released a few days after the immudb release.

[tomekkolo]

add note about SDK updates (go documentation, python, .net, node)

[tomekkolo]

add a note about immudb-tools updates (at least replicator tool was updated ?)

[tomekkolo]

add links to documentation on FIPS and replication

[byo]

add a note about immudb-tools updates (at least replicator tool was updated ?)

I'm not sure what's the status here, @arriqaaq did we update anything in immudb-tool ?

[byo]

@NickAnderegg FYI

[NickAnderegg]

@byo I've updated the release notes in-place, since that's apparently a thing that GitHub can do now? No content changes, just structural, looks good 👍

[arriqaaq]

add a note about immudb-tools updates (at least replicator tool was updated ?)

I'm not sure what's the status here, @arriqaaq did we update anything in immudb-tool ?

@byo Not yet, plan to do it post 1.4 is released, else would have to import an RC tag in go mod

[byo]

@NickAnderegg:

When this occurs, the state of the surviving nodes will diverge from the state computed by the immudb client, because the new primary node is missing the most recent commits tracked by the clients.

To be fully correct, it should be something like:

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.

WDYT?

[NickAnderegg]

@byo Looks good to me, and definitely clarifies the exact issue that can occur

[byo]

@NickAnderegg I've added some more info about replication speed, can you take a look?

[NickAnderegg]

@byo Looks good. Just one typo and a few commas, which I've fixed in-place!