|Build status (Linux)|
|Build status (Windows)|
|Project status||Usable, between alpha and beta|
|Production-readiness||Depends on your risk tolerance|
PumpkinDB is a compact event sourcing database engine, featuring:
- Immutable key/value storage
- ACID transactions
- Binary keys and values (allows any encoding to be used: JSON, XML, Protobuf, Cap'n Proto, etc.)
- An embedded programming language (PumpkinScript)
- A range of event indexing and querying primitives
What is event sourcing?
Event sourcing is a pattern in which, instead of storing the current state of the data and using it as a source of truth, one should immutably record the full series of actions taken and designate that log as a source of truth instead. This approach can simplify tasks in complex, changing domains by avoiding the need to synchronize data models and domain models. It also provides great auditing and transactional capabilities, as well as opportunities for lossless error correction.
What is PumpkinDB?
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.
Applications communicate with PumpkinDB by sending small PumpkinScript programs over a network interface (or API when using PumpkinDB as an embedded solution).
PumpkinDB offers a wide array of primitives for concurrency, storage, journalling, indexing and other common building blocks.
Why is it an event sourcing database engine?
The core ideas behind PumpkinDB stem from the so called lazy event sourcing approach which is based on storing and indexing events while delaying domain binding for as long as possible. That said, the intention of this database is to be a building block for different kinds of event sourcing systems, ranging from the classic one (using it as an event store) all the way to the lazy one (using indices) and anywhere in between. It's also possible to implement different approaches within a single database for different parts of the domain.
Instead of devising custom protocols for talking to PumpkinDB, the protocol of communication has become a pipeline to a script executor. This offers us enormous extension and flexibility capabilities.
To name a few:
- Low-level imperative querying (as a foundation for declarative queries)
- Indexing filters
- Subscription filters
Trying it out
You can download PumpkinDB releases from GitHub.
You can try out latest PumpkinDB HEAD revision by using a docker image:
$ docker pull pumpkindb/pumpkindb
Alternatively, you can build the image yourself:
$ docker build . -t pumpkindb/pumpkindb
Run the server:
$ docker run -p 9981:9981 -ti pumpkindb/pumpkindb 2017-04-12T02:52:47.440873517+00:00 WARN pumpkindb - No logging configuration specified, switching to console logging 2017-04-12T02:52:47.440983318+00:00 INFO pumpkindb - Starting up 2017-04-12T02:52:47.441122740+00:00 INFO pumpkindb_engine::storage - Available disk space is approx. 56Gb, setting database map size to it 2017-04-12T02:52:47.441460231+00:00 INFO pumpkindb - Starting 4 schedulers 2017-04-12T02:52:47.442375937+00:00 INFO pumpkindb - Listening on 0.0.0.0:9981
Finally, connect to it using
$ docker run -ti pumpkindb/pumpkindb pumpkindb-term 172.17.0.1:9981 # replace IP with the docker host IP
Building from the source code
You are also welcome to clone the repository and build it yourself. You will need Rust Nightly to do this. The easiest way to get it is to use rustup
$ rustup install nightly $ rustup override set nightly # in PumpkinDB directory
After that, you can run PumpkinDB server this way:
$ cargo build --all $ ./target/debug/pumpkindb 2017-04-03T10:43:49.667667-07:00 WARN pumpkindb - No logging configuration specified, switching to console logging 2017-04-03T10:43:49.668660-07:00 INFO pumpkindb - Starting up 2017-04-03T10:43:49.674139-07:00 INFO pumpkindb_engine::storage - Available disk space is approx. 7Gb, setting database map size to it 2017-04-03T10:43:49.675759-07:00 INFO pumpkindb - Starting 8 schedulers 2017-04-03T10:43:49.676113-07:00 INFO pumpkindb - Listening on 0.0.0.0:9981
You can connect to it using
$ ./target/debug/pumpkindb-term Connected to PumpkinDB at 0.0.0.0:9981 To send an expression, end it with `.` Type \h for help. PumpkinDB> ["Name" HLC CONCAT "Jopn Doe" ASSOC COMMIT] WRITE. PumpkinDB> ["Name" HLC CONCAT "John Doe" ASSOC COMMIT] WRITE. PumpkinDB> [CURSOR DUP "Name" CURSOR/SEEKLAST DROP CURSOR/VAL] READ (Get last value). "John Doe" PumpkinDB> [CURSOR DUP "Name" CURSOR/SEEKLAST DROP DUP CURSOR/PREV DROP CURSOR/VAL] READ (Get previous value). "Jopn Doe"
(The above example shows how one can query and navigate for values submitted at a different time, using low level primitives).
You can change some of the server's parameters by creating
[storage] path = "path/to/db" # By default, mapsize will equal to the size of # available space on the disk, except on Windows, # where default would be 1Gb. # `mapsize` is a theoretical limit the database can # grow to. However, on Windows, this also means that # the database file will take that space. # This parameter allows to specify the mapsize # in megabytes. # mapsize = 2048 [server] port = 9981
This project is in its very early days and we will always be welcoming contributors.
Our goal is to encourage frictionless contributions to the project. In order to achieve that, we use Unprotocols C4 process. Please read it, it will answer a lot of questions. Our goal is to merge pull requests as quickly as possible and make new stable releases regularly.
In a nutshell, this means:
- We merge pull requests rapidly (try!)
- We are open to diverse ideas
- We prefer code now over consensus later
To learn more, read our contribution guidelines
We also maintain a list of issues that we think are good starters for new contributors.
Support us with a monthly donation and help us continue our activities. [Become a backer]
Become a sponsor and get your logo on our README on Github with a link to your site. [Become a sponsor]