# BaikalDB: a distributed HTAP database that speaks the MySQL protocol

> BaikalDB is a C++ distributed HTAP database from Baidu that accepts MySQL-protocol clients and MySQL-style SQL, then pushes projections, filters, aggregations and sorts into a distributed execution layer, with optional full-text search over inverted indexes. It is aimed at petabyte-scale structural data, and the README routes all operational detail to the project wiki.

**baidu/BaikalDB** — BaikalDB, A Distributed HTAP Database.

- Repository: https://github.com/baidu/BaikalDB
- Stars: 1,240 · Forks: 174
- Language: C++
- License: Apache-2.0
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/baidu-baikaldb

## A MySQL-wire database aimed at petabyte scans

BaikalDB describes itself as a distributed HTAP database, which is the claim to test first. Hybrid transactional and analytical processing means the same store serves row-level transactional work and large analytical scans, and the README states that BaikalDB supports sequential and randomised real-time read and write of structural data at petabyte scale.

The adoption hook is compatibility. The database speaks the MySQL protocol and supports a MySQL-style SQL dialect, and the README says users can migrate their data storage from MySQL to BaikalDB seamlessly. That means existing clients, migrations and reporting queries keep working, which is the difference between evaluating a new database and re-platforming an application.

The primary language is C++, and the acknowledgements name the pieces it stands on: RocksDB, brpc and braft. The README also credits the TiDB and Impala teams, saying their design schemes were referred to while designing and developing BaikalDB, and thanks the Baidu TafDB team for a space-efficient snapshot scheme based on braft. The design lineage is documented rather than hidden, which is useful when you are judging how a failure will behave.

## Projections and operators as the unit of execution

The interesting part of the README is the list of internal capabilities: projections, filter operators corresponding to the SQL WHERE or HAVING clause, aggregation operators corresponding to GROUP BY, and sort operators corresponding to ORDER BY. Together they describe a distributed execution layer that decomposes a query into pushable pieces rather than shipping every row to one node.

That is the difference between BaikalDB and a plain MySQL server sitting in front of sharded tables. The intent is that a query touching a few columns of a very wide table reads only those columns, and that filtering and aggregation happen close to the data. The README makes a performance claim about this shape, stating that in a typical scenario hundreds of millions of rows can be scanned and aggregated in a few seconds. That figure comes from the project's own description, so treat it as a design intention to verify against your own data rather than a number to quote in a business case.

The user-facing side stays plain SQL, and that is deliberate. Analysts keep writing SELECT statements and the pushdown happens underneath.

## Full-text search through inverted indexes and word segmentation

BaikalDB also does full-text search, and the mechanism is described concretely: it builds inverted indices after word segmentation. For an English corpus that means tokenising the text into words before indexing, which is a choice with consequences for languages that do not separate words with spaces, and for queries that are substrings rather than words.

The user-facing path is short. You add a FULLTEXT KEY type index when creating the table, then use the LIKE clause in queries, and the README describes this as a fuzzy search feature. There is no separate query syntax to learn and no separate index type to administer beyond the key you declare in the schema, which is a good fit for teams whose search needs are modest.

The trade-off is that the segmentation step is where the behaviour lives, and the README does not document how the segmenter handles CJK text, stemming, stop words or custom dictionaries. If your requirement is full-text search across languages, that is a question to take to the wiki and to your own test data before committing to the index type.

## The storage and transport layer comes from RocksDB, brpc and braft

A distributed database lives or dies by its consensus and storage choices, and BaikalDB does not present these as novel. The acknowledgements name RocksDB as one of the libraries that support important features, brpc as the RPC layer, and braft as the raft implementation, and they credit the Baidu TafDB team with a space-efficient snapshot scheme built on braft.

The last point is the one an operator should care about. Snapshots are what let a node restart, rebalance or restore from a copy of state, and a space-efficient scheme changes how much disk and how much copy time a large cluster needs. The credit is given to another team, and the scheme is described in one sentence, so the details belong in the wiki and in your own capacity planning.

The other lineage note is about SQL engines rather than storage. The README says the design schemes of TiDB and Impala were referred to during development, which is a reasonable explanation for a MySQL-dialect distributed SQL layer that pushes operators down. It is a pointer for further reading, not a substitute for reading the wiki's architecture notes.

## Building from source means CMake, protobuf definitions and conf templates

The README gives no installation or deployment steps. It says to see the GitHub wiki for more explanation, and that is where the operational documentation lives. This section therefore describes what the repository layout shows rather than inventing a command sequence.

The tree is a conventional C++ project. CMakeLists.txt sits at the root with a cmake/ directory beside it, which is the standard CMake arrangement for a project of this size. A proto/ directory holds the interface definitions, and a separate watt_proto/ directory suggests the protocol definitions are split between the data plane and a separate service protocol. A conf/ directory holds configuration, and a test/ directory holds tests, with sysbench/ present for load generation and ci/ for pipeline scripts. The baikal-client/ directory is a client package, and insider-preview/ is a separate area whose purpose the README does not explain.

The build has to be driven from those files, and the wiki is the only documented route. Anyone adopting this should read the wiki pages on building and deployment before trying to assemble a command line, and should plan for a C++ toolchain, a protocol buffer compiler and the transitive dependencies of the named libraries.

## Where BaikalDB is the wrong tool

The first wrong-tool case is a workload that fits comfortably in one MySQL server. A distributed HTAP engine exists to solve problems that a single node cannot, and if your data is not petabyte scale, the operational cost you take on is not repaid. Sharding a database that did not need sharding is a common and expensive mistake.

The second is a team that needs a fully specified SQL feature set. The README speaks of a MySQL-style dialect rather than MySQL itself, and it does not document which statements, functions or behaviours are supported, what happens to a transaction spanning nodes, or how isolation levels are implemented. Compatibility is real enough for a migration to start, but the gap between MySQL-compatible and MySQL-equivalent is exactly where the surprises live.

The third is a full-text search requirement that outgrows a LIKE clause over an inverted index. BaikalDB offers a workable mechanism, and a project needing ranking, phrase queries, fuzzy matching or a stemmer per language will have to check the wiki and the segmenter behaviour before assuming it fits. For a team that just needs to find rows containing a token, it is more than enough.

## Apache-2.0, v5.0.0, and a last push in June 2026

The project is licensed under the Apache License 2.0, with the LICENSE file at the repository root and a licenses/ directory for the dependencies it carries. Apache-2.0 is a permissive grant with an explicit patent clause, which is why many companies find it acceptable inside a product, but that is a question for your own legal review rather than one to settle from a README.

On versions, the release list shows BaikalDB v5.0.0 dated 2026-06-15, v4.1.0 from 2026-02-26 and v4.0.2 from 2025-09-11. The last push was on 2026-06-15, the same day as the v5.0.0 tag, which means the 5.0 line is where the recent work landed and where the wiki's upgrade notes will matter most if you are on 4.x.

The release spacing also tells you something about the upgrade rhythm. A major version in a year, with patch releases behind it, is a cadence you should budget for, because a distributed database that changes its wire protocol or storage format across major versions turns an upgrade into a project rather than a pull. The C++ build adds a second cost: compiling the tree is part of every upgrade, so the cost of a version jump is measured in build time as well as downtime.

## Conclusion

Adopt BaikalDB when you have petabyte-scale structural data, an existing MySQL toolchain, and a workload that mixes transactions with wide analytical scans, and start with the MySQL-protocol compatibility so migration is a matter of connection settings. Do not adopt it as a drop-in MySQL replacement for a small workload, since the operational surface of a distributed system is larger than the code changes imply, and do not expect the README to configure it for you, because the setup instructions live in the wiki. Before you commit, read the wiki pages for deployment, confirm the version you pick against the v5.0.0 tag, and check the Apache-2.0 LICENSE file before you redistribute any of it.

## FAQ

### Is BaikalDB compatible with MySQL?

The README states that BaikalDB is compatible with the MySQL protocol and supports a MySQL-style SQL dialect, so users can migrate their data storage from MySQL to BaikalDB seamlessly. It is a compatible dialect rather than MySQL itself, and the README does not enumerate the supported statements.

### What does BaikalDB push down into a query?

The README lists projections, filter operators matching the SQL WHERE or HAVING clause, aggregation operators matching GROUP BY, and sort operators matching ORDER BY, so a query is decomposed into pushable pieces instead of shipping every row to one node.

### How does full-text search work in BaikalDB?

BaikalDB builds inverted indices after word segmentation. You declare a FULLTEXT KEY type index when creating the table and then use the LIKE clause in your queries, which the README describes as the fuzzy search feature.

### What licence does BaikalDB use?

The README states that baidu/BaikalDB is licensed under the Apache License 2.0, and a LICENSE file is present at the repository root alongside a licenses/ directory for dependencies.

### Where are the BaikalDB build and deployment instructions?

The README does not give installation steps and points to the GitHub wiki for more explanation. The repository itself shows a CMake build with CMakeLists.txt and a cmake/ directory, a proto/ directory for interface definitions and a conf/ directory for configuration.

## Sources

- [baidu/BaikalDB on GitHub](https://github.com/baidu/BaikalDB)
- [Issues](https://github.com/baidu/BaikalDB/issues)
- [License: Apache-2.0](https://github.com/baidu/BaikalDB/blob/master/LICENSE)
- [README](https://github.com/baidu/BaikalDB/blob/master/README.md)
- [Releases](https://github.com/baidu/BaikalDB/releases)

---

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