Hyrise: an in-memory database system built to be taken apart

A platform for experiments, not a product to deploy

Hyrise is described as a research in-memory database system, developed by HPI since 2009 and entirely rewritten in 2017. The rewrite is documented in an EDBT 2019 paper, Hyrise Re-engineered, whose bibtex entry the README asks you to use when citing the current version, and the previous version of the system is still available as an archived repository.

The stated goal is to provide a clean and flexible platform for research in the area of in-memory data management, and the reason for that phrasing is the sentence that follows: the architecture allows the authors, their students and other researchers to conduct experiments around new data management concepts. In other words, the system is designed to be modified. That is a different objective from the one a production database has, and it shapes every decision in the codebase, from the operator implementations to the strictness of the compiler settings.

To make those experiments realistic rather than toy, the README points at two features: broad SQL support and query plan optimisations. The repository topics list the column store, C++, database, in-memory database and SQL, which is the honest summary of what kind of system this is.

The licence is MIT, the default branch is master, and the last push was on 2026-10-19. There are no GitHub releases, which fits a project where you build from source and pin a commit rather than a version. The project page is at HPI, the same institution that hosts the paper and the earlier version of the system.

For orientation, the repository points newcomers to a contributor guidelines file, a glossary that defines most of the terms and abbreviations used in the code, and a step by step guide in the wiki. That glossary is a small sign of how much jargon a research database accumulates.

The benchmarks are wired in, and the CI runtimes are not results

Hyrise ships benchmark suites out of the box, and the reason is practical rather than promotional: it removes the work of generating data, loading CSVs and finding a query runner, so you can produce performance numbers with a single command. The binaries are named with a common prefix, so the suite is run through the hyriseBenchmark executables.

The list is a proper research portfolio. TPC-DS and TPC-H are there, along with the Join Order benchmark, the Star Schema benchmark, and JCC-H, which is run by calling the TPC-H binary with a flag. TPC-C is marked as in development with no proper optimisation done yet, which is the kind of honesty that tells you the coverage is not uniform.

Then comes the caveat, and it is the most useful line in the section. The query plans are generated in the CI pipeline with possibly many stages running in parallel, and different CI runs might be executed on different machines. The conclusion the README draws is that reported runtimes are not to be taken as solid benchmark performance numbers.

That is a significant limitation for anyone who reads a CI dashboard as a performance history, and it is a good example of a research project documenting its own measurement weakness. The query plans themselves are still published as artefacts per benchmark, and those are useful for studying what the planner produced. The timings attached to them are not.

So the honest way to use the built-in benchmarks is to run them yourself on a machine you control, with a fixed configuration, and to treat the published artefacts as plan examples rather than as a scoreboard.

Three setup paths, and the Docker image is not the CI image

The build documentation offers three routes, and the choice tells you what kind of environment the project expects.

The native route is the recommended one. There is an install_dependencies.sh script that installs all the listed dependencies and submodules, which is simpler than assembling them by hand from the dependency list in DEPENDENCIES.md, where the same packages are given for brew install or apt-get install depending on the platform. The script was tested under macOS Monterey 12.4 and Ubuntu 22.04, and the compilers are recent versions of clang and gcc.

The Nix route gives you a hermetic shell in one command:

nix-shell resources/nix --pure

The --pure flag is recommended because it keeps your host's packages out of the environment, which for a project with this many native dependencies is the difference between a reproducible build and a mysterious one.

The Docker route builds an image from the Dockerfile in the repository root:

docker build -t hyrise .
docker run -it hyrise

The image is based on Ubuntu 25.04 and installs the toolchain, clang and gcc versions, cmake, ninja, LLVM 20, boost, hwloc, NUMA, PostgreSQL and SQLite development packages, TBB, valgrind and graphviz, which tells you the scope of the system: it links against a good deal of native infrastructure, and the build is not a small one.

And then the file begins with a warning that is easy to miss: changes to the Dockerfile do not automatically affect the Docker image the CI server uses, because that image has to be built and pushed manually. So the image you build from the repository and the image your continuous integration uses are not the same thing unless someone did that manual step.

A related note in the file explains why the Python packages are installed with the break-system-packages flag: virtual environments are not straightforward in a scripted Jenkins pipeline, and the CI runs on Python 3.11 or newer.

Strict compiler flags are a policy with a documented escape hatch

The build section contains a small decision that colours the whole developer experience.

Hyrise uses very strict compiler flags by default, beyond the usual warning level and including treating warnings as errors. The README says that on an officially supported environment this should not be an issue, and that if you simply want to test Hyrise on a different system and run into issues, you can relax the build:

cmake -DHYRISE_RELAXED_BUILD=On ..

That switch is a good piece of design for a research system. The strictness is the point in a codebase that a large number of people modify for experiments, because it catches the mistakes that would otherwise be silently introduced by a new operator implementation. But it is also the first thing that blocks a newcomer on an unusual platform, so the escape hatch being documented and named is what makes the policy usable.

The build itself is a CMake project, and the README recommends out-of-source builds in a separate directory named after the build type, with cmake .. to configure. The repository carries a CMakeLists.txt, a PreLoad.cmake, a cmake/ directory, a .clang-format and a .clang-tidy configuration, which together set both the formatting and the static analysis rules for a C++ project of this size.

Continuous integration runs on Jenkins, with a build status badge and a coverage badge that reports from an LLVM coverage report, and a CodeFactor badge for the automatic code review checks. The Jenkinsfile at the repository root is the pipeline definition, and the .gitmodules file matches the submodules the dependency script pulls in.

The dependency list is a research lab in a file

The Dockerfile and the Python requirements file together describe what kind of work happens in this repository, and the Python one is the more surprising.

The Python requirements are not for the database. They are for the tooling around it: black and flake8 for the formatting and linting of the scripts, numpy, pandas, scipy, matplotlib and seaborn for the analysis and plotting of benchmark and experiment results, pexpect for driving interactive processes in tests, termcolor and terminaltables for readable terminal output, and PyDriller for mining the repository's own commit history.

One entry explains itself in a comment. psutil is used in the PGO and BOLT script to obtain the CPU count in a NUMA-bound environment, which tells you that the project builds with profile guided optimisation and BOLT, and that it cares about how many cores the machine has when it lays out the binary.

The native side of the dependency list is equally telling. Boost, hwloc for hardware topology, libnuma for memory locality, TBB for parallelism, PostgreSQL and SQLite development headers, readline and ncurses for the interactive shell, valgrind for memory checking, graphviz for the query plan visualisations, and LLVM 20 with clang-tools for compilation and analysis. The presence of a PostgreSQL development package alongside SQLite is the kind of detail that only makes sense in a system that has to be compared against real engines.

The result is a build that needs a compiler toolchain, a fair amount of native libraries and a Python environment for the analysis scripts. That is the honest cost of a platform where experiments are expected to be run, plotted and written up rather than merely compiled.

Editorial conclusion

Adopt Hyrise if you are doing research on in-memory data management and want a system where the query planner, the storage layout and the operator implementations are all meant to be modified, since that is the stated purpose of the rewrite and the reason the architecture is kept flexible. Do not adopt it as a production database, because the project describes itself as a research system, the benchmark runtimes it publishes come from parallel CI stages on different machines, and Mac support is explicitly discouraged for benchmarking. Before you build it, decide which of the three setup paths fits your environment, and if you use the Docker route remember that the image in the repository is not the one the CI uses, so it has to be built and pushed yourself.

Frequently asked questions

Official sources

1. hyrise/hyrise on GitHub
2. Issues
3. License: MIT
4. Project website
5. README