For many of us, a database is a means to store our objects for future retrieval and use. We need our stored objects to withstand applications being terminated and restarted, we need multiple programs to be able to work with the same objects safely and intuitively, and we need our databases to be distributed and fault-tolerant to ensure our objects don't get lost or corrupted. Despite how common this use case is, many (if not most) databases are not designed to store object graphs, and as a result we're forced to use object-relational mappings that clunkily represent our objects and object graphs, with leaky APIs, performance issues because of contention caused by the grouping of unrelated objects, and often unexpected semantics.
GoshawkDB is a distributed, transactional, fault-tolerant data store, specifically designed for storing objects and object graphs. It supports only the strongest form of transactional isolation possible (strong serializability) which gives it intuitive semantics without surprises. A GoshawkDB cluster distributes objects across nodes with configurable redundancy and automatic sharding. Transactions continue to complete until a majority of copies of each object become unavailable due to failures. But most of all, it rejects the traditional database concepts of named tables or collections, and instead allows you to precisely mirror your objects and object graphs in the store.
Matthew has been building and studying concurrent and distributed systems for over ten years. He built the first prototype of RabbitMQ, and contributed heavily to the design and implementation of many of its core features. He worked on the initial implementation of the Weave router in 2014. In 2015, out of general frustration with other databases and the difficulties of deciphering their semantics and guarantees, he built GoshawkDB: a distributed, transactional, fault-tolerant object store.