v1.6.11

Separate centos and debian build

v1.6.10

Try to prebuild across linux too

test-release

Do hexdump first

v1.6.8b

Try to build macos arm64

v1.6.8

Skip old tests to run

Faster gets and query/range retrieval

This release includes a significant overhaul of how get and query/range retrievals are performed to reduce the amount of native calls and the number of JS objects that have to be transmitted across the native calls. This also facilitates and accompanies adding support for V8's new fast-api-calls feature, which also improves performance. This can yield over a 50% performance improvement in get operations, and over twice the speed for iterating through ranges, with small payloads where deserialization is not the dominant cost. There are also very large improvements in the performance of count operations and offset handling as well.

Also related to these changes is switching (back) to serializing and deserializing keys in JS (instead of C++), which reduces the number of JS value/objects cross the native call barrier. This also opens the door for more customized JS key serialization strategies (negation, custom UUID handlers, and potentially more performant little endian format).

Faster binary access, binary and count functions, ordered-binary data encoding

The latest point releases include performance improvements for accessing binary data. This should improve performance when using encoding: 'binary'. There are also now dedicated binary methods, getBinary/getBinaryFast that are available for getting binary data even if the store is using a different encoding.

There are now count functions (getCount, getKeysCount, getValuesCount) for faster access to getting a count of entries in a range.

ordered-binary is now available as an encoding option. This may be useful when create index stores that are primarily use to store references to keys in other stores (and this is often done in combination with the dupSort option).

Improved resizing and transaction ordering

Database resizing has now been completely internalized and done on the fly within LMDB itself, and does not require throwing any errors or restarting any transactions, which makes it more efficient, easy and deterministic to run transaction callbacks.
There are now new defaults and options for ordering asynchronous transactions and standalone operations.
Synchronous transactions now execute as a child transaction where possible (inside an existing transaction without writemaps or caching).

v1.4.0

Changes to the default LMDB configuration to use the new remapping functionality by default, which provides a simpler approach to database growth without have to use resize events. Also, writemaps (with syncing) have been disabled by default in Windows since they are not syncing properly.

Asynchronous and Child Transactions

The major new addition for this release is support for asynchronous transactions and child transactions. This significantly expands the ability to define more complex transactions with arbitrary code, while still taking advantage of asynchronous, batched transaction handling with off-thread start and commit operations. In addition, there is also support for child transactions (which are also asynchronous by default), which allows for asynchronous transaction operations to have full abort/roll-back functionality. See the documentation for the new transactionAsync and childTransaction methods.

As part of these changes the transaction method is now deprecated (which runs a synchronous transaction), as it will be converted to running asynchronous transactions in the future. Also the batch thresholds have been removed as there are too many complications with trying to run an asynchronous batch synchronously.