Release notes 1.3
We’re pleased to announce immudb version 1.3. This version brings some new notable changes, 40% higher performance and a lot of other improvements and some bug fixes.
You can find the new release here for all major platforms:
Regarding SDKs, please make sure to check the compatibility list:
New Support plans
In response to its growing popularity and increasing adoption by enterprises, Codenotary, the primary contributor to the open source immudb, provides three levels of support.
- Community: The free support plan that offers community members notifications of new releases and features.
- Project: At $3,000 a year, project subscribers are promised 12-hour response times and 5 day resolutions. They are also offered 2 hours of setup and training credits, as well as 1 hour of development support.
- Business: At $16,000 a year, business subscribers are promised 8-hour response times and 3 day resolutions. They are also offered 12 hours of setup and training credits, as well as 8 hours of development support. Managed services are also included in the business plan, including: training, development, configuration, monitoring, and daily Software Bill of Materials (SBOM) reference of the runtime.
In this version we’ve extended queries on the KV level by adding value revisions. This brings up an easy to use and elegant way to access historical values for keys such as getting the first version (revision 1) or a previous value (revision -1). You can quickly check how it works with newest
immuclient by following our updated User quickstart guide or by writing an application using revision using our SDKs.
Initial support for
Temporal SQL queries based on time
When dealing with historical values on the SQL layer, it is now possible to use time expressions next to transaction ids for specifying historical values. Queries such as
SELECT * FROM sales SINCE '2022-01-06 11:38' UNTIL '2022-01-06 12:00' are now perfectly valid. You can find more info in the SQL reference.
Information about the SQL catalog can now be read directly using SQL. For that purpose we’ve added few built-in functions into our SQL dialect such as
DATABASES(). Read more about this feature in the SQL reference
In this release we also worked on the immudb documentation available at https://docs.mmudb.io/. Next to hundreds of smaller changes, the new menu structure will help finding useful resources. Most notably, the developer documentation is now split between the Key Value and SQL operations.
There are many more features added in this release. Most notably immudb now supports the
USE [DATABASE] <dbname> and
UNION SELECT SQL statements increasing the SQL compatibility. In addition to that, the Scan operation on the KV layer has now extended set of parameters allowing much greater filtering of scanned results.
Starting with 1.3 release, immudb will now return an error if the amount of rows returned from the
ZScan will be greater than the allowed maximum (1000) and the limit argument was not set. We’ve found out that the previous behavior lead to a very dangerous and hidden bugs if the caller made an assumption that those calls returned all available results if the limit was not given.
To retrieve results larger than 1000 elements, pagination with a proper limit value should be used. This is the same requirement as before however it currently requires explicit limit value.
In order to handle arbitrary result sizes, future releases of immudb will focus on streaming APIs where entries will be retrieved from the server in an incremental way.
You can find the full change log and the release download here: