In 56d3cb5, maximum base of key components is 62.
Increase this limit to ideally KeyMax.

There are no safeguards against misbehavior due to concurrent access to the database. Implement them.

README.md files must be manually updated after documentation changes.
Better if they just point to GoDoc site, so updated documentation is generated on the fly.

Implement Keep as a storage library of typed data for the Go language.

... at least the number of keys in database for starters.

SmallestKeyNotLessThan can be used to discover the first key and travel upwards.
A method is missing for discovering the last key and travel downwards.

Instad of a single io.Writer or io.Reader in Load and Save calls, make LazyDB support multiple values (eg slices of Reader/Writer) and "do the expected thing" when saving and loading them.

Minimally the ordering of values shall be respected when saving and loading. If so, the caller is expected to bind semantics in the ordering of values for a given key.

(In b98892c)

Following BerkeleyDB's nomenclature "Put" and "Get" sounded good at first, until "Save" and "Load" were created... Seems odd because Load() is synonymous for Get() in the implementation, however Save() and Put() have distinct meanings.

How about:

• rename Put() to SaveAs()
• remove Get()

So there will remain: Save(), SaveAs() and Load()?

As doc says, "If wipe method fails or is interrupted before termination, subsequent calls to the same directory will fail due to detection of non empty, non concur storage directory."
Fix this.

Implement getters to properties of LazyDB type (initialized, dir etc...)

Concurrent execution of free key lookup mechanism in Save() method may eventually return the same key.
This leads to distinct concurrent Save() operations return the same key, one overwritting another.

Finding values in a Keep collection by comparation is currently "possible" by brute force only. Keep needs indexing mechanisms for fast lookup of values.

A suggestion would be to accept user comparation functions between values of typed data -- say, "Less(a, b MyType) bool" -- and maintain a sorted list of value references that honors these functions.

LazyDB performance is heavily dependent to filesystem effectiveness in handling a large number of small files. What filesystems are good choices for this workload? Find out and document it.

(in afe94ef)

Base of key components for subdirectory naming in filesystem is currently harcoded at 36 (characters [0..9a..z]).
Is this optimal for the client workflow? Can a smaller or larger value perform better?

In order to provide choice, make the key component base a parameter when creating a database.