immudb - The lightweight, high-speed immutable database

# SDKs api

# Contents

# Connection and authentication

immudb runs on port 3323 as the default. The code samples below illustrate how to connect your client to the server and authenticate using default options and the default username and password. You can modify defaults on the immudb server in immudb.toml in the config folder.

# Mutual tls

To enable mutual authentication, a certificate chain must be provided to both the server and client. That will cause each to authenticate with the other simultaneously. In order to generate certs, use the openssl tool: generate.sh.

./generate.sh localhost mysecretpassword

This generates a list of folders containing certificates and private keys to set up a mTLS connection.

# Disable authentication

You also have the option to run immudb with authentication disabled. However, without authentication enabled, it's not possible to connect to a server already configured with databases and user permissions. If a valid token is present, authentication is enabled by default.

# Verify state signature

If immudb is launched with a private signing key, each signed request can be verified with the public key. In this way the identity of the server can be proven. Check state signature to see how to generate a valid key.

# State management

It's the responsibility of the immudb client to track the server state. That way it can check each verified read or write operation against a trusted state.

# Tamperproof reading and writing

You can read and write records securely using built-in cryptographic verification.

# Verified get and set

The client implements the mathematical validations, while your application uses a traditional read or write function.

# Writing and reading

The format for writing and reading data is the same both in Set and VerifiedSet, just as it is for reading data both in both Get and VerifiedGet.

The only difference is that VerifiedSet returns proofs needed to mathematically verify that the data was not tampered. Note that generating that proof has a slight performance impact, so primitives are allowed without the proof. It is still possible get the proofs for a specific item at any time, so the decision about when or how frequently to do checks (with the Verify version of a method) is completely up to the user. It's possible also to use dedicated auditors to ensure the database consistency, but the pattern in which every client is also an auditor is the more interesting one.

# Get and set

# Transaction by index

This section is not yet ready for immudb 0.9. We are working on it in order to improve it and we are close to deliver. Stay tuned!

# Verified transaction by index

This section is not yet ready for immudb 0.9. We are working on it in order to improve it and we are close to deliver. Stay tuned!

# History

The fundamental property of immudb is that it's an append-only database. This means that an update is a new insert of the same key with a new value. It's possible to retrieve all the values for a particular key with the history command.

History accepts the following parameters:

  • Key: a key of an item
  • Offset: the starting index (excluded from the search). Optional
  • Limit: maximum returned items. Optional
  • Desc: items are returned in reverse order. Optional
  • SinceTx:

# Counting

# Scan

The scan command is used to iterate over the collection of elements present in the currently selected database. Scan accepts the following parameters:

  • Prefix: prefix
  • SeekKey: initial key to returns. Optional
  • Desc: sorting order. Optional
  • Limit: maximum returned items. Optional
  • SinceTx: transaction limit id. 0 is the last server transaction. Optional

# References

SetReference is like a "tag" operation. It appends a reference on a key/value element. As a consequence, when we retrieve that reference with a Get or VerifiedGet the value retrieved will be the original value associated with the original key. Its VerifiedReference counterpart is the same except that it also produces the inclusion and consistency proofs.

# SetReference and verifiedSetReference

# Get and verifiedGet

When reference is resolved with get or verifiedGet in case of multiples equals references the last reference is returned.

# Resolving reference with transaction id

Creating references withSetReferenceAt and VerifiedSetReferenceAt fix a reference to a specific item in time.

# Secondary indexes

On top of the key value store immudb provides secondary indexes to help developers to handle complex queries.

# Sorted sets

The sorted set data type provides simplest secondary index you can create with immudb. That's a data structure that represents a set of elements ordered by the score of each element, which is a floating point number. The score type is a float64 to accommodate the maximum number of uses cases. 64-bit floating point gives a lot of flexibility and dynamic range, at the expense of having only 53-bits of integer.

When an integer64 is cast to a float there could be a loss of precision, but the insertion order is guaranteed by the internal database index that is appended to the internal index key.

ZAdd can reference an item by key or by index.

ZScan accepts following arguments:

  • Set: the name of the collection
  • SeekKey
  • SeekScore
  • SeekAtTx
  • InclusiveSeek
  • Limit: the maximum items returned,
  • Desc: items are returned in score ascending or descending order
  • MinScore: minimum score filter
  • MaxScore: maximum score filter
  • SinceTx

# Transactions

GetAll, SetAll and ExecAll are the foundation of transactions in immudb. They allow the execution of a group of commands in a single step, with two important guarantees:

  • All the commands in a transaction are serialized and executed sequentially. No request issued by another client can ever interrupt the execution of a transaction. This guarantees that the commands are executed as a single isolated operation.
  • Either all of the commands are processed, or none are, so the transaction is also atomic.

# GetAll

# SetAll

A more versatile atomic multi set operation

SetBatch and GetBatch example

# ExecAll

ExecAll permits many insertions at once. The difference is that is possible to to specify a list of a mix of key value set, reference and zAdd insertions. The argument of a ExecAll is an array of the following types:

  • Op_Kv: ordinary key value item
  • Op_ZAdd: ZAdd option element
  • Op_Ref: Reference option element

It's possible to persist and reference items that are already persisted on disk. In that case is mandatory to provide the index of the referenced item. This has to be done for:

  • Op_ZAdd
  • Op_Ref If zAdd or reference is not yet persisted on disk it's possible to add it as a regular key value and the reference is done onFly.

ExecAll

# Tamperproofing utilities

# Current State

CurrentState returns the last state of the server.

# User management

User management is exposed with following methods:

  • CreateUser
  • ChangePermission
  • ChangePassword

Password must have between 8 and 32 letters, digits and special characters of which at least 1 uppercase letter, 1 digit and 1 special character.

Admin permissions are:

  • PermissionSysAdmin = 255
  • PermissionAdmin = 254

Non-admin permissions are:

  • PermissionNone = 0
  • PermissionR = 1
  • PermissionRW = 2

# Multiple databases

Starting with version 0.7.0 of immudb, we introduced multi-database support. By default, the first database is either called defaultdb or based on the environment variable IMMUDB_DBNAME. Handling users and databases requires the appropriate privileges. Users with PermissionAdmin can control everything. Non-admin users have restricted permissions and can read or write only their databases, assuming sufficient privileges.

This example shows how to create a new database and how to write records to it. To create a new database, use CreateDatabase method.

# HealthCheck

HealthCheck return an error if immudb status is not ok.

# Immudb SDKs examples

Examples in multiple languages can be found at following links: