Just recently, we’ve released PumpkinDB 0.2 and it’s a nice incremental improvement over our very first release that attracted quite a lot of gazers, despite a very minimal announcement (heck, just a link to a very minimal website, we had no other materials!). With this release, we’re hoping to attract the next wave of early adopters and contributors to help us figuring out project’s next challenges.

PumpkinDB is essentially a database programming environment, largely inspired by core ideas behind MUMPS. Instead of M, it has a Forth-inspired stack-based language, PumpkinScript. Instead of hierarchical keys, it has a flat key namespace and doesn’t allow overriding values once they are set. Core motivation for immutability was that with the cost of storage declining, erasing data is effectively a strategical mistake. While not intended for general purpose programming, its main objective is to facilitate building specialized application-specific and generic databases with a particular focus on immutability and processing data as close to storage as possible, incurring as little communication penalty as possible.

In this release, the most notable external change was splitting PumpkinDB into multiple crates. Why is this important? Well, the biggest benefit is that now one can:

a) embed PumpkinDB into their Rust (and soon, perhaps, C) applications and

b) build their own custom PumpkinDB-compatible servers with added or reduced functionality very easily.

After all, PumpkinDB is a database engine first and foremost and this change has actually allowed us to build on top of it. As an example (and I hope to have enough capacity to do this relatively soon), this functionality would be used to build a successor for es4j — a lazy event sourcing engine that can be both embedded (where feasible) or accessed remotely.

The introduction of the Dispatcher API in this release has enabled us to split up standard library functionality into manageable modules. Very importantly, it allows for smooth addition, re-configuration and removal of APIs to the engine, so that the aforementioned custom engines can be built easily.