# BqLog: one logging core shared by seven languages

> BqLog is a Tencent maintained logging library whose C++ core is wrapped for C++, Java, Kotlin, C#, TypeScript, Python and Go, so one log object and one file format are shared across a mixed codebase. It targets shipped products that cannot afford to lose logs or stall on a full disk.

**Tencent/BqLog** — A lightweight, high-performance, industrial-grade cross-language logging library (C++/Java/C#/Kotlin/TS/Python/Go), battle-tested in Honor of Kings.

- Repository: https://github.com/Tencent/BqLog
- Stars: 709 · Forks: 59
- Language: C++
- License: NOASSERTION
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/tencent-bqlog

## The problem the project names is the impossible triangle

BqLog is described as a lightweight, high-performance, industrial-grade cross-language logging library, and the README opens with the situations it is meant to solve. The first is a client product, especially a game, that wants to satisfy an impossible triangle at the same time: easy troubleshooting, which means logging as much as possible, good performance, which means logging as little as possible, and saving storage space, which pushes toward not logging at all. The second is a backend service whose current logging library cannot handle high-concurrency scenarios, causing log loss or application stalls. The third is a codebase written in several languages at once, or in a language that the available loggers do not cover. The project says it has been widely used in online products such as Honor of Kings, which is a statement about where the design came from rather than a benchmark claim.

## A single core underneath seven language wrappers

The architecture is visible in the repository layout. There is an `include/` directory, a `src/` directory for the C++ implementation, and a `wrapper/` directory for the language bindings, with `demo/` folders for cpp, csharp, go, java, nodejs and python, plus a `demo_category_log.h` and its `.txt` counterpart that demonstrate categorised logging. The README states the compatibility surface directly: Windows, macOS, Linux, iOS, Android, HarmonyOS, OpenHarmony and the Unix family, with C++, Java and Kotlin, C#, Python, TypeScript and ArkTS and Go sharing one core and, in the project's phrase, even one log object. The language list on the badges is C++, Java, C#, Kotlin, TypeScript, Python and Go. The consequences of that design are concrete. A cross-language team gets a single log file format rather than one per runtime, and the same configuration semantics, which matters when a crash spans a native module and a managed layer.

## One log object, and where the bytes go

The logging model is deliberately code-first. The README describes the ergonomics as one line to create a log and one line to write, with the internals kept as transparent as possible and without complicated configuration, and with every interface designed to be friendly to IDE code completion. The design goals section spells out the performance posture: the logging threads and the consumer thread should use as little CPU, memory and disk IO as possible, and the project says it does not optimize for benchmark scores but that every optimization targets real use. The measured figures the README does give are about footprint rather than throughput. In the benchmark case of ten threads with two million log entries each, the whole benchmark process peaks at no more than 3.1 MB on macOS, and on mobile platforms the library itself generally uses around 1 MB. There is also a real-time compressed log format with high compression, and optional hybrid encryption combining asymmetric and symmetric schemes at close to no performance cost.

## The bad day is the design target

The section that most distinguishes this library from a typical logger is the one about failure. The README says logs written before a crash are recovered after it, a full disk neither crashes nor hangs the application, corrupted files are recovered as far as possible, and log files can be encrypted to protect privacy. Asynchronous logging supports crash recovery and tries to avoid data loss, which is the direct answer to the backend scenario in which a busy service loses logs or stalls. This is also why the project ships an encryption option, a decoder, and a recovery path rather than only an appender. The trade-off is that an on-disk format with recovery metadata is a more complex thing to integrate than a simple console or file logger, and the decoder in the repository is part of the cost of that complexity.

## What v2.7.0 changed, and the ABI warning

The current release is 2.7.0, published on 2026-10-16, following 2.6.0 on 2026-10-07 and 2.5.0 on 2026-09-24, so the line is moving quickly. The new features are C++20 modules, with `import bq.log;` as an alternative to the classic header include and no change to the logging code, and a macro-free fast log entry point in the form `log.fast_info<"...">(args...)`, which the README describes as the same speed as the macro version but with full IDE support and usable with any log object. Package manager support expanded to Homebrew, vcpkg and NuGet. Multi-process support arrived, letting several processes share one log directory, each with its own crash recovery data. The release also carries a warning that matters for anyone upgrading: it changes the ABI, so the headers or language wrapper and the library have to be upgraded together.

## Where to get it, and how the build is organised

The distribution channels are broad and match the language story. The README badges point to a Homebrew formula, a vcpkg port, a NuGet package, Maven Central artifacts for both the java and android coordinates, a PyPI package, an npm package under the `@pippocao/bqlog` scope, an ohpm package for OpenHarmony, a Go module path under `github.com/Tencent/BqLog/go/v2`, a Unity package, and an Unreal plugin on Fab. The Integration Guide in `docs/` is the reference for each of them, and the API Reference documents the fast mode entry points. The build itself is CMake, with `CMakeLists.txt` and `CMake_utils.txt` at the root, and the repository also carries a `benchmark/` directory, a `test/` directory, a `plugin/` directory, a `pack/` directory, a `tools/` directory and formatting scripts for both Windows and Unix shells. Development guidance is in `DEVELOPMENT_GUIDELINES.md`, and a changelog with a Chinese counterpart tracks each release.

## Where BqLog is the wrong choice

Three limits are visible from the documentation itself. The first is the absence of a configuration-file culture. The stated design is that configuration lives in code and the internals stay transparent, which is a good fit for a game client where the build already has a configuration system, and a bad fit for an operations team that wants to change log levels by editing a file on a running server. The second is the pace of the project and the ABI churn, since releases landed three weeks apart across 2.5.0, 2.6.0 and 2.7.0, and 2.7.0 breaks the ABI. Adopting a fast-moving core means pinning versions deliberately and budgeting for the upgrade. The third is the trade-off in the encryption and recovery design, which is a substantial amount of machinery to own and understand before it works for you. And the project states the boundary of its own claim plainly: it does not optimize for benchmark scores, so a team shopping for the fastest logger on a chart should look elsewhere.

## Conclusion

BqLog fits a studio or team whose product spans several languages and needs one log format, one viewer and one set of files, and who care about crash recovery, disk pressure and encryption more than about a large feature surface. It is a poor fit if you want a config-file driven logger with pluggable sinks, since the design pushes configuration into code, and the v2.7.0 release changes the ABI, so headers and library must be upgraded together. Before you adopt it, read the Integration Guide for the package manager that matches your stack, check the API Reference for the fast mode, and run the benchmark on your own machine. The last push was on 2026-10-20 and Release 2.7.0 shipped on 2026-10-16.

## FAQ

### Which languages does BqLog support?

The README lists C++, Java, C#, Kotlin, TypeScript, Python and Go, with the C++ core shared across the wrappers so that different languages can use one log object and one log format. Game engines such as Unity and Unreal are also supported.

### How do I install BqLog?

Packages are published through Homebrew, vcpkg, NuGet, Maven Central for java and android, PyPI, npm under the `@pippocao/bqlog` scope, ohpm for OpenHarmony, a Go module path, a Unity package and an Unreal plugin on Fab. The Integration Guide in the documentation covers each route.

### Does the BqLog 2.7.0 release break compatibility with earlier versions?

Yes. The release notes carry a warning that this release changes the ABI, so the headers or the language wrapper and the library must be upgraded together. Version 2.7.0 was published on 2026-10-16.

### What does BqLog do when the log disk is full or the app crashes?

The README states that logs written before a crash are recovered afterwards, that a full disk neither crashes nor hangs the application, and that corrupted files are recovered as far as possible. Log files can also be encrypted with hybrid encryption for privacy.

## Sources

- [Issues](https://github.com/Tencent/BqLog/issues)
- [README](https://github.com/Tencent/BqLog/blob/main/README.md)
- [Releases](https://github.com/Tencent/BqLog/releases)
- [Tencent/BqLog on GitHub](https://github.com/Tencent/BqLog)

---

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