# StoneDB: a MySQL-compatible HTAP engine that has moved on to ShannonBase

> StoneDB is a column store engine for MySQL that gave InnoDB a run for its money on analytical queries, with a 10 to 1 compression ratio and no index requirement for ad hoc work. The catch is in the first line of the README, which states that the repository is no longer maintained and that development has moved to ShannonBase, so this is a project to study rather than to adopt.

**stoneatom/stonedb** — https://github.com/Shannon-Data/ShannonBase

- Repository: https://github.com/stoneatom/stonedb
- Website: https://www.shannonbase.org
- Stars: 884 · Forks: 141
- Language: C++
- License: GPL-2.0
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/stoneatom-stonedb

## The first line of the README is the whole story now

Before describing the technology, the state of the project has to come first, and the README is unambiguous about it.

There is a notice that this repository is no longer maintained. The StoneDB project has been migrated to a new repository and is now under active development as ShannonBase, at github.com/Shannon-Data/ShannonBase. All future updates, bug fixes and new features will be made in the new repository, and this repository is archived and will not receive any further maintenance. The README invites readers interested in real-time HTAP databases to follow the new repository, try ShannonBase and join the community.

So the repository you are reading is a historical artefact with a pointer at the top. The documentation, the getting started guide and the architecture notes all still describe a system that is no longer being worked on here, and the release list on the project record shows why: the most recent tags are 5.7-v1.0.4-alpha from 2023-06-30, 8.0-v1.0.1-beta from 2023-06-01 and 8.0-v1.0.1-alpha from 2023-05-17. All alpha or beta, all from 2023, and the default branch is named stonedb-5.7-dev.

One oddity deserves a note rather than a conclusion. The project record says the repository is not archived, and the last push to it was on 2026-09-21, which is more recent than any tag. Whatever caused that push, the README's own statement is that no further maintenance will happen here, and that is what a reader should plan around.

The licence is GPL-2.0, which is a detail with real consequences for a database, and it is covered further on below.

## A MySQL server with a column store engine bolted on

The technical description in the README is a MySQL-compatible high-performance hybrid transaction and analytical processing database that provides analytical processing abilities to MySQL. The claim that matters is the compatibility one: running systems can be migrated to StoneDB without any code changed.

That compatibility is not a thin wrapper. The top level repository listing is the evidence, and it looks like MySQL because it largely is MySQL. There is a libmysql directory, a libmysqld directory, a sql directory, a storage directory, a client directory, a vio directory, a mysys directory, a strings directory, a regex directory, a plugin directory, plus libbinlogevents and libbinlogstandalone for the replication layer. There is a mysql-test directory and a unittest directory.

What StoneDB added is a storage engine, and the two engine names in the documentation reveal the version split. For MySQL 5.7 or later the engine is called tianmu, and for version 5.6 it is called stonedb. The configuration snippet in the README shows the same switch:

```shell
[mysqld] 
# For version 5.7 or later, the engine should be set to tianmu
default-storage-engine=tianmu
# For version 5.6, the engine should be set to stonedb
# default-storage-engine=stonedb
default-tmp-storage-engine=MyISAM
binlog-format=STATEMENT
```

So the design is a column store living inside a MySQL-compatible server, reachable through the ordinary SQL interface, which is what makes the migration claim possible. The default-storage-engine line is what you set in my.cnf to make new tables land in the column store rather than in InnoDB, and the engine name depends on which MySQL version you are running, which is a sharp edge for anyone moving between the 5.6 and 5.7 lines.

## Column format over RocksDB, and the compression claim

The storage story is described in the section that follows the create table example, and it is where the most interesting engineering claim sits.

StoneDB data is stored in Column format and persists to RocksDB. All data is compressed, and the compression ratio can be 10:1 to 40:1. The second claim in the same section is that StoneDB can achieve competitive performance when processing ad-hoc queries, even without any indexes created.

The no-index claim is the one that separates this from ordinary MySQL behaviour, and it is the reason a column store is interesting for a transactional server. In InnoDB, an ad hoc query over columns you did not think to index is a full scan. In a column store, the columns are already laid out together, so a filter on a column the schema designer never indexed is cheap. The trade is elsewhere: writes go to a column structure, which suits appends and aggregates rather than the random row updates that a transactional workload generates, and that is the tension the hybrid label is trying to resolve.

The dependency list confirms the shape. The verified packages are marisa 0.77, RocksDB 6.12.6 and Boost 1.66, alongside GCC 7.3 or higher, Make 3.82 or later and CMake 3.7.2 or later. RocksDB is the storage layer, and the presence of Boost and marisa alongside it is the fingerprint of a MySQL fork rather than a standalone database.

The performance and compression figures in the README are the vendor's own, given as ten times the query performance of InnoDB, ten times the load performance, and a 10:1 to 40:1 compression ratio. The repository also links a StoneDB Limitations page and a Codecov badge, so the project acknowledged the limits alongside the claims, and the limitations page is the document to read before drawing any conclusion from the numbers.

## Building it, configuring it, and creating the first table

The getting started section is complete enough to follow, and it covers both a container route and a source route.

The container route is the quick one, with a Docker Hub image described as installable and deployable in two minutes, and a separate guide for compiling inside a Docker container. The source route is documented per distribution, for Ubuntu 20.04, CentOS 7.x and Red Hat 7.x, with the officially supported platforms being CentOS 7.x or higher, Ubuntu 20.04 or higher and RHEL 7.x.

Configuration happens in my.cnf, and the snippet above is the minimum. Initialization differs by version, because the tool changed:

```bash
# For version 5.6
cd /path/to/your/path/bin && ./mysql_install_db --basedir=/stonedb/install/ --datadir=/stonedb/install/data/ --user=mysql

# For version 5.7 or later
cd /path/to/your/path/bin && ./mysqld --initialize --basedir=/stonedb/install/ --datadir=/stonedb/install/data/ --user=mysql
```

The instance is then started with mysqld_safe against the defaults file:

```bash
mysqld_safe --defaults-file=/path/to/my.cnf --user=mysql &
```

And a table is created with the engine named explicitly:

```sql
CREATE TABLE `example_table` (
  `id1` bigint(20) NOT NULL DEFAULT '0',
  `id1_type` int(10) NOT NULL DEFAULT '0',
  `id2` bigint(20) NOT NULL DEFAULT '0',
  `id2_type` int(10) NOT NULL DEFAULT '0',
  `data` varchar(255) NOT NULL DEFAULT '',
  `time` bigint(20) NOT NULL DEFAULT '0',
  `version` int(11) NOT NULL DEFAULT '0',
) ENGINE=tianmu;
```

Two things about that schema are worth pausing on. The columns are named id1, id1_type, id2, id2_type, data, time and version, which is the shape of a wide table with a data column and per-column type markers, and the version column is the kind of thing an MVCC or column versioning scheme needs. And the trailing comma before the closing parenthesis in the example is a small sign that this is illustrative rather than copy-paste ready.

The README also has a section on switching from MySQL to StoneDB in production, which is the part that matters most for the intended audience, though the excerpt cuts off before the procedure.

## The GPL-2.0 licence is the real obstacle for a database

The licence deserves its own paragraph because a database is not an ordinary dependency.

StoneDB is released under the terms of the GPL version 2, and the project record agrees, with the licence field reading GPL-2.0. For a library that you link into your application, a copyleft licence is a manageable constraint because you can comply by publishing the source of the combined work. For a database server, the picture is different in practice, because a database is deployed as a separate process that your application connects to over a network, and the questions about what counts as modification and about distributing a derived work in a container image are exactly the kind that make a legal team nervous.

That is worth thinking about before anyone builds a business on this code, and it is a second reason to look at ShannonBase instead, since the successor project is the one where the future work, and presumably the current licensing conversation, lives.

The project also carries a CODE_OF_CONDUCT.md and a CONTRIBUTING.md, and the README links a WeChat group and the community channels, which is a project that ran a real community rather than a code drop. The Docker Hub pull badge and the codecov badge suggest a period when the project was actively measured and packaged.

The version numbering is the other detail. The tags carry both a StoneDB line and a version prefix, 5.7-v1.0.4-alpha and 8.0-v1.0.1-beta, so there were parallel efforts against two MySQL versions, and neither reached a stable release. An alpha tag that never became a 1.0 is a reasonable place for a project to stop and move, which is broadly what happened here.

## Where StoneDB is the wrong answer today

Three situations rule it out, and the first one is not a judgement call.

The first is any new deployment. The project states that the repository is no longer maintained, that all future updates and fixes happen in ShannonBase, and that this repository will receive no further maintenance. Adopting an unmaintained database with alpha-era tags, when the same team ships a successor, is not a trade-off you can justify on features.

The second is if your workload is genuinely transactional. The design is a column store inside a MySQL server, and the case made in the README is about analytical processing, ad hoc queries and compression. A workload that updates individual rows constantly is the case a row store is good at, and a hybrid engine that resolves that tension is a compromise by definition. The MySQL compatibility buys you an easy migration path, but it also means the engine inherits MySQL's assumptions, and the storage engine interface is a constraint on how much the column format can optimise.

The third is if you want a supported platform. There is no commercial support arrangement described here, and the build matrix is pinned to CentOS 7, Ubuntu 20.04 and RHEL 7 with specific package versions, which are themselves old enough that a new system would not be built on them.

What the repository is genuinely good for now is as a reference. The source tree is a complete, readable implementation of a column store engine inside a MySQL-compatible server, and for a database engineer that is a rare and instructive thing to read. The knowledge in it did not disappear with the move to ShannonBase, and the migration notice points at exactly where the maintainers think that knowledge is best used. So the sensible order is: read StoneDB to understand the approach, then look at ShannonBase to see whether it is what you actually want to run.

## Conclusion

StoneDB fits a database engineer studying how a column store was bolted onto the MySQL server, and the source tree is still worth reading because it shows the storage engine interface in a real implementation. It is the wrong choice for a new deployment, since the project itself states that the repository is no longer maintained and that all future work happens in ShannonBase, and the last tagged alpha builds date from 2023. Before you consider anything built on this code, check ShannonBase for the current state of the project, and if you are evaluating StoneDB itself as a historical reference, read the limitations page linked from the README, because the documented feature claims and the documented limits are equally part of what the project offers.

## FAQ

### Is StoneDB still maintained?

No. The README states that the repository is no longer maintained, that the project has been migrated to ShannonBase at github.com/Shannon-Data/ShannonBase, and that this repository is archived and will not receive any further maintenance. The recent tags are 5.7-v1.0.4-alpha from 2023-06-30 and 8.0-v1.0.1-beta from 2023-06-01.

### What is StoneDB and how does it relate to MySQL?

It is a MySQL-compatible high-performance hybrid transaction and analytical processing database that adds analytical processing abilities to MySQL. Running systems can be migrated to it without code changes, and the column store is implemented as a storage engine named tianmu for MySQL 5.7 or later and stonedb for version 5.6.

### How is StoneDB data stored and how well does it compress?

The documentation states that StoneDB data is stored in Column format and persists to RocksDB, that all data is compressed, and that the compression ratio can be 10:1 to 40:1. It also claims competitive performance on ad-hoc queries even without any indexes created, with RocksDB 6.12.6, marisa 0.77 and Boost 1.66 among the verified packages.

### How do I configure and start StoneDB?

You set default-storage-engine=tianmu for version 5.7 or later, or stonedb for version 5.6, in the my.cnf file, initialize with mysqld --initialize for 5.7 or later, and start the instance with mysqld_safe against the defaults file. The supported platforms are CentOS 7.x or higher, Ubuntu 20.04 or higher and RHEL 7.x, built with GCC 7.3 or higher.

### What licence is StoneDB released under?

StoneDB is released under the terms of the GPL version 2, with the project record listing GPL-2.0. The README also links a StoneDB Limitations page alongside the performance and compression claims, and describes ShannonBase as the place where ongoing development continues.

## Sources

- [License: GPL-2.0](https://github.com/stoneatom/stonedb/blob/stonedb-5.7-dev/LICENSE)
- [Project website](https://www.shannonbase.org)
- [README](https://github.com/stoneatom/stonedb/blob/stonedb-5.7-dev/README.md)
- [Releases](https://github.com/stoneatom/stonedb/releases)
- [stoneatom/stonedb on GitHub](https://github.com/stoneatom/stonedb)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/stoneatom-stonedb