The HyPer DBMS is an in-memory database which aims to achieve high performance for both OLTP and OLAP workload; it creates a consistent snapshot of the transactional data by forking the OLTP process, so that the OLAP queries could operate on the consistent virtual memroy snapshot. Besides, the HyPer DB group proposed a serializable Multi-Version Concurrency Control (MVCC) model which could provide full serializability isolation. Furthermore, they designed the Adaptive Radix Tree (ART) which is a high speed index for main-memory-based database systems. Last but not least, HyPer uses Just-In-Time (JIT) compilation to generate LLVM codes for the incoming queries, which boosts the performance of the database and minimizes the memory traffic.
HyPer is a DBMS project from the Technical University of Munich (TUM) database group. In the beginning, their objective was to build a hybrid in-memory database; during the process of developing HyPer, they published lots of paper about different parts of the system. HyPer is not open source, but it provides a WebInterface (http://hyper-db.de/interface.html) where we could execute queries on the HyPer system. HyPer is still in active development and the next big step of the HyPer group is to extend the functionality of HyPer to "exploratory workflows that are deeply integrated into the database kernel".
It's positive that HyPer supports sort-merge joins; as for the hash join, they implemented a NUMA-aware hash join algorithm, but they didn't mentioned whether they have integrated hash join into HyPer or not.
ScyPer (Scaled-out HyPer) is a version of HyPer, which horizontally scales out on shared-nothing commodity hardware
HyPer creates consistent backups and checkpoints by taking efficient snapshots.
HyPer supports normal views where a query would define a virtual table.
The adaptive radix tree (ART) index is the default indexing structure in HyPer. Two important features of ART are adaptive node structure and path compression.
No documentations from HyPer specifically state that HyPer supports foreign key constrains, but in their fast serializable MVCC paper, they mentioned a senario where an transacion deletes a primary key and another concurrent transacion inserts a foreign key which refers to that primary key.
HyPer supports a novel serializability validation mechanism which is adapted from precision locking. Instead of tracking dependencies like the Serializable Snapshot Isolation (SSI) implemented in PostgreSQL, HyPer would "read predicates and validate the predicates against the undo log entries".
The stored procedures in HyPer are written in a custom, iterator-free language called HyPerScript.
HyPer uses physical logging to support data durability.
In HyPer, the storage layout would change according to the access patterns; for OLTP workload, it uses row store approach by organizing relations as arrays of entire records; as for the OLAP workload, it uses column store approach by partitioning relations into vactors of attribute values.
HyPer uses Just-In-Time (JIT) code compilation to compile transacions and queries into efficient LLVM assembly code.
HyPer is not a non-relational database (a.k.a NoSQL database) like MongoDB which is document-oriented database or HBase which uses column family; instead, HyPer is a relational database; however, the relations are not always maintained as arrays of entire records; the table layout in HyPer would change according to the workload, so HyPer is also the so-called New-SOL database.