Groonga is a fulltext search engine that also stores columns

Search and column storage in one engine

The definition in the README is two words long: an open-source fulltext search engine and column store. That combination is the reason Groonga exists as a separate project rather than as a plugin for somebody else's database. In a typical setup, fulltext search is a feature of the primary store, which means your document text is either indexed inside a general purpose database engine or handled by a separate search service and copied back and forth. Groonga puts inverted index style search and column oriented storage in the same engine, so a query can read a column and search text without crossing a network boundary. The implementation language is C, and the project is the successor to Senna, which is the lineage that explains both the age of the codebase and the plugin oriented structure. The user is an application developer who needs Japanese capable fulltext search in an application, since the repository ships a bundled MeCab dictionary and the Onigmo regular expression engine, both of which come from that tradition.

The README points you at the docs site for everything

It is worth saying plainly what this README does not contain, because that shapes how you evaluate the project. There is no install command, no configuration example, no query example and no API description. The reference manual lives in the doc/source directory and online at groonga.org/docs/, and the README offers three shortcut links: the install page, the tutorial, and a page on how to build as a developer. The community page is linked as well. So the documentation lives on a separate site and this file acts as a signpost. That is a real difference in how you will spend your first hour with the project, and it means the repository itself is not the place to answer operational questions. It also means the project has documentation assets that a self contained repository would not have, which is a reasonable arrangement for a project with long accumulated docs, but you should expect to be reading a website rather than a file.

The build supports autotools and CMake side by side

The top level tree is the best evidence of how the project is put together, and it is dense. There is a classic autotools build with configure.ac, Makefile.am, config.sh.in, autogen.sh and setup.sh, and next to it a CMake build with CMakeLists.txt, CMakePresets.json, cmake/, config.h.cmake.in and build.sh. Both are present in the same tree, which tells you the migration is incomplete rather than planned, and that a contributor can arrive from either direction. Supporting files are split the way a mature C project splits them: src/, lib/, include/ and plugins/ hold the engine, data/ holds data files, doc/ holds the documentation sources, test/ holds the test suite, benchmark/ holds benchmarks, tools/ holds helper programs, packages/ holds distribution packaging, bindings/ holds language bindings, examples/ holds examples with a Makefile.am and dictionary/ and web/ subdirectories, and ci/ and dockerfiles/ hold the continuous integration setup. There is also a.pre-commit-config.yaml and a.clang-format, so formatting is enforced by tooling rather than by review.

Vendored dependencies carry their own licences

Groonga bundles third-party code and documents it in the README, which is more than most projects do. mruby is vendored under vendor/mruby-source under the MIT licence, with details in vendor/mruby-source/MITL. Onigmo, the regular expression engine, is vendored under vendor/onigmo-source under the BSD licence, with details in vendor/onigmo-source/COPYING. An image asset is bundled too, the Zulip icon at doc/source/images/zulip-icon-128x128.png, under the Apache 2.0 licence, with copyright held by Dropbox, Kandra Labs and contributors between 2011 and 2020, used under the Zulip licence. The project's own licence is LGPL-2.1, with the COPYING file at the root of the tree. The dependency set is pinned in the repository as well, through files named bundled_lz4_version, bundled_mecab_version, bundled_mecab_naist_jdic_version, bundled_rapidjson_version and bundled_xxhash_version, which is how a project like this tracks the exact upstream version of every vendored copy. For a legal review, the point is that a Groonga licence question has more than one component, and the LGPL terms of the engine itself are a separate matter from the permissive terms of the bundled parts.

CI runs on Alpine, Arch and WASI

The compose.yaml file in the repository shows how the continuous integration environment is assembled, and it is more informative than a badge. Each service builds its own image from the dockerfiles/ context and caches it under the ghcr.io namespace of the project, keyed by the repository name. The alpine-3.20 service pulls the ci-alpine-3.20 image, builds from alpine.dockerfile with an ALPINE_LINUX_VERSION build argument of 3.20, mounts the source directory at /source with delegated sharing, sets shm_size to 512mb, and runs /source/dockerfiles/run.sh as its command. The arch-linux service does the same with arch-linux.dockerfile and the ci-arch-linux image. A third service, wasi, builds from the ci-wasi image with a wasi.dockerfile. The presence of a WASI build in the matrix is the notable part, since it means the engine is expected to compile for a WebAssembly sandbox and not only for Linux and macOS. The same file carries the standard LGPL notice header that clear-code projects use.

Embed the engine or run it as a server

The architectural choice behind an adoption decision is whether Groonga lives inside your process or beside it. The engine is a C library, and the repository layout shows both the pieces of a server distribution, with lib/ and src/ alongside plugins/, packages/ and the tooling in tools/, and the pieces of an embeddable dependency, with include/, the headers, and bindings/ for other languages. The README does not document either integration path in detail, so a reader will need the reference manual at groonga.org/docs/ rather than this file. The trade-off is the usual one. Embedded, you get search in the same process as your data and no network hop, at the cost of linking a C library with plugins into your build and owning its upgrade path. Separate, you get an isolated service that other applications and languages can share through its protocol, at the cost of another thing to run, monitor and secure. Groonga supports both shapes, which is why the plugins/ directory and the bindings/ directory both exist.

Sixteen years of releases and a steady patch rhythm

The maintenance picture is the strongest part of this project's story. The recent release list shows Groonga 16.1.2 on 2026-09-29, Groonga 16.1.3 on 2026-10-08 and Groonga 16.1.4 on 2026-10-16, and the last push to the repository was on 2026-10-20, with the repository not archived. That is a project shipping patch releases roughly weekly and merging changes the same week. The version numbering itself is informative: a 16.x series for a project whose successor lineage started with Senna, and a release train where 16.1.2 to 16.1.4 arrived inside a fortnight. The licence is LGPL-2.1, which is a consideration for anything you link or redistribute, and the bundled components add MIT and BSD terms on top. That licensing question is one for your own counsel. What the repository tells you plainly is that the code is moving, that dependencies are pinned in tracked version files, and that the CI matrix covers multiple Linux distributions plus a WebAssembly target.

Editorial conclusion

Groonga suits a team that wants an embeddable search engine with column storage in the same process, and that can live with the weight of a C codebase carrying decades of compatibility surface, a plugin directory and vendored dependencies it must track. It is a poor fit for a project that wants a hosted search service with no integration work, since the README documents nothing about operating it. Verify first that groonga.org/docs/install.html matches your platform, decide whether you will embed the engine or run it as a server process, and read the licence obligations of the bundled pieces, since mruby is MIT, Onigmo is BSD and the project itself is LGPL-2.1.

Frequently asked questions

Official sources

1. groonga/groonga on GitHub
2. License: LGPL-2.1
3. Project website
4. README
5. Releases