HamsterDB

This post was a bit of a test to see if I could write a serious post about a database platform called Hamster.  I think I just made it 🙂

With all the noise over key/value stores recently, we should keep in mind that this technology isn’t exactly new.  It is being applied to new problems, but many of the foundations have been around for decades.  Probably the oldest of them all, Berkley DB came into existence during the mid ‘80’s and now has over 200 million deployments (according to the Oracle web site).

HamsterDB, while not having the same pedigree of Berkley, has been steadily worked on by Christoph Rupp for the last 5 years.  I spoke to Christoph yesterday about his release of a new edition of Hamster.

Hamster primarily has been a single threaded data store for embedded use, however Christoph has expanded Hamster into two editions, the second being a multi-user transactional platform.  This month sees the release of the BETA build of this edition.  Key Features of the NoSQL HamsterDB Transactional Key/Value Store:

• ACID Compliance
• Lock Free Architecture (transactions fail on conflict rather than block)
• Transaction logging & fail recovery (redo logs)
• In Memory support – can be used as a non-persisted cache
• B+ Trees – supported but additional indexes are user maintained (see below)

Performance details are still sparse, but the embedded edition has done very well when compared with BerkleyDB.  HamsterDB is also licensed using a mixture of GPL and commercial licenses.  It provides native C++ support but wrappers exist for .NET, Java & Python.

Hamster is a pure key/value store so doesn’t have the feature set of the hybrids, such as MongoDB or Wistla, i.e. lookups are by key only, B-Tree indexes are supported but must be manually maintained by the application etc.  HamsterDB also doesn’t have a distribution layer so is for single node use.

But, from the perspective of a simple, lightweight, high performance key/value alternative HamsterDB looks very interesting.