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".
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.
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".
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.
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.
Multi-version Concurrency Control (MVCC)
HyPer used MVCC scheme to handle both OLTP and OLAP queries.