ZincSearch: a Go search engine that stopped short of being Elasticsearch

What the project claims, and the sentence that qualifies it

The README opens with a note before the project name. If your use case is log search, application logs or security logs, rather than app search, the note says you should look at OpenObserve instead, and describes that project as built in Rust for the log search case. A project putting its own boundary in the first paragraph of its README is rarer than it should be, and it changes how you read everything that follows.

The pitch itself is straightforward. ZincSearch is described as a search engine doing full text indexing, a lightweight alternative to Elasticsearch that runs using a fraction of the resources. Underneath, it uses bluge, reached through the `vcaesar/riot` fork rather than upstream bluge directly, which is the single most consequential dependency fact in the repository.

The comparison to Elasticsearch is drawn on two axes: complexity and resources. The README argues Elasticsearch is very good but complex, resource-hungry and more than a decade old, and positions ZincSearch as easier to operate without a couple dozen knobs to tune. The claim is that you can get it running in two minutes.

There is a third claim that needs reading carefully: a drop-in replacement for Elasticsearch if you are just ingesting data through APIs and searching through Kibana. The parenthetical immediately undercuts it. Kibana is not supported, and ZincSearch ships its own UI instead.

The feature list is short and each item is a decision

The features section runs to eight numbered items and the stack line above them is `go + gin + react`. Reading the list as a set of deliberate omissions is more useful than reading it as a checklist.

There is full text indexing, a single binary for installation and running with releases built for multiple platforms, a React web UI embedded in that binary, compatibility with Elasticsearch APIs for ingestion covering both the single record and bulk API, out of the box authentication, schema-less operation where different documents in one index may carry different fields, disk-based index storage, and aggregation support.

Two of those deserve unpacking. Schema-less storage means no mapping to define up front, which removes the largest single piece of Elasticsearch setup work and is the reason a small team can adopt this in an afternoon. Aggregation support is present but the comparison table rates the ZincSearch GUI as basic, against Very Advanced for OpenObserve, so the honest reading is that aggregation exists and dashboards do not.

What is absent is as informative. There is no mention of sharding, replication, or snapshots anywhere in the README, and the comparison table has a row for high availability whose ZincSearch column reads Not available. Index storage on disk is stated, with no object store option listed, unlike the OpenObserve column which names S3, GCS, MinIO and swift.

The dependency list explains the architecture better than the README does

The `go.mod` file is the most information-dense document in the repository, and it is worth reading before the documentation. The module path is `github.com/zincsearch/zincsearch` with a Go directive of `1.26.7`.

The direct requirements name the storage and search layers directly: `github.com/vcaesar/riot` at v1.23.1 is the indexing library, `github.com/vcaesar/ice` at v1.2.3 sits next to it, and `github.com/zincsearch/wal` at v1.2.6 plus `go.etcd.io/bbolt` v1.5.0 point at a local write-ahead log over bbolt. Storage of that shape is what lets the whole engine ship as one file you run, and it is also what bounds how much data the design is comfortable with.

The rest of the list reads like an operations checklist: `github.com/prometheus/client_golang` and `github.com/zincsearch/go-gin-prometheus` for metrics, `github.com/grafana/pyroscope-go` for profiling, `github.com/getsentry/sentry-go` for error reporting, `github.com/shirou/gopsutil/v4` for system stats, and `github.com/segmentio/analytics-go/v3` for usage analytics. `github.com/gin-gonic/gin` is the HTTP layer and `github.com/swaggo/swag` generates the API documentation. `github.com/go-ego/gse` is the Chinese segmenter, which tells you tokenisation is not English-only. Two entries deserve a second look: `vitess.io/vitess` at v0.24.3, a SQL layer, and `go.etcd.io/etcd/client/v3` at v3.7.1, which suggests multi-node coordination exists in some form even though the README advertises no high availability.

The most telling dependency is `github.com/vcaesar/riot`. A fork of bluge maintained by the same person who authored most of the recent ZincSearch commits means the indexing layer is not waiting on an upstream that may not accept your feature request.

Three beta releases in three days tell you where the project is

The release history is the most recent thing in the repository, and it compresses a lot of information into a short window. All three releases landed in September 2026.

`v1.0.0-beta1` on 2026-09-13 came after `v0.4.11` and its entire changelog is one pull request: refactoring the underlying code and improving performance, and updating the UI. A version bump from a 0.4 line to a 1.0 beta attached to a single refactoring commit is a signal that the internals changed substantially while the external shape was meant to hold.

`v1.0.0-beta2` the next day is a normal maintenance release with seven changes: a fix to the contributing docs, a fix to README links that were returning 404s, more tests for the analysis code, a dependency update that also lowered the minimum build version to Go 1.26, a bump of gopsutil to v4, an optimization of the syntax guide and date pickers for close and mobile screens, and a smaller Go binary via goreleaser. The README fix and the frontend optimization in the same release are consistent with a project that had just rewritten itself and was cleaning up its own documentation.

`v1.0.0-beta3` on 2026-09-16 has four changes and is the most interesting of the three. It fixes a bug where cached credentials were not evicted when a user was deleted, which is a real security-adjacent issue in a product with out-of-the-box authentication. It adds a show-password icon and i18n support to the login and change-password screens in the frontend, and a change-password feature for the web UI. It also updates CI and the goreleaser config for Go 1.27.

That combination is worth naming plainly. Someone deleting a user, finding the credentials still usable from a cache, and fixing it, is the profile of an actively worked-on project. But three beta tags in seventy-two hours after a rewrite is also the profile of an unstable interface, and the pushes to the `main` branch on 2026-09-16 confirm work is landing now.

The comparison table is the most useful and least flattering section

The README ends, as far as it is captured here, with a feature-by-feature table against OpenObserve. Because it is an honest comparison rather than a marketing one, it works better as a decision tool than any of the surrounding prose.

The rows: ideal use case is App search for ZincSearch against Logs, metrics, traces (Immutable Data) for OpenObserve. Storage is Disk against Disk, Object (S3), GCS, MinIO, swift and more. Max data supported is 100s of GBs against Petabyte scale. High availability is Not available against Yes. ES API compatibility is Yes for both. The GUI is Basic against Very Advanced, including dashboards. Cost is Open source for both.

Read together, that table describes a search engine that fits comfortably inside a single well-specified server's disk and chokes well before it, with no replication story, and that would be the wrong tool for anything an operations team needs to page someone about.

There is also a CI note at the end of the README that is worth internalising before you fork. The nightly dev image push fails on forks, and the error is explicit about the cause:

Error: buildx failed with: ERROR: failed to build: failed to solve: failed to push ghcr.io/zincsearch/zincsearch-dev:0.4.11-8792c59-dev: denied: permission_denied: The requested installation does not exist.

The workflow logs into GHCR with the repository's `GITHUB_TOKEN`, which can only push packages under the owner of the repository running the workflow. The fix the README suggests is to run the workflow from `zincsearch/zincsearch` or change `env.IMAGE` in `nightly.yml` to your own namespace. Note that the failing tag in that message is still `0.4.11`, from the pre-rewrite version line.

Deployment paths and what the repository tree reveals

Installation instructions are not in the README body. The Getting started section is two lines long: check the Quickstart page in the documentation at `zincsearch-docs.zinc.dev`. That is a deliberate choice, and it means the README cannot be used to evaluate whether the quickstart is any good.

What the repository tree does show is the set of supported deployment shapes, and it is a longer list than a two-minute startup claim suggests. There is a `docker/` directory and a `Dockerfile`-adjacent setup, a `helm/` directory for Kubernetes installs, a `k8s/` directory, a `distribution/` directory for packaged builds, a `cmd/` directory for the Go entry points, `pkg/` for the implementation, a `frontend/` directory holding the React UI, `embed.go` and `embed_test.go` for the Go embed of the built frontend into the binary, and `sh/` for shell scripts.

There are also `examples/` containing `load_single_docment.py`, `search.py` and a `word-files/` directory. Those two Python files are the closest thing to a runnable usage sample in the repository, and they describe the shape of the ingest and query path: one script loads a single document, the other searches. The Go reference badge in the README points at the module on pkg.go.dev, which is the reference for the server side.

The CI picture is three workflows named in the Build section: `ci.yml` for lint, `go test` on Linux, macOS and Windows, and coverage; `nightly.yml` for the dev image `ghcr.io/zincsearch/zincsearch-dev:nightly`; and `release.yml` for `v*` tags via goreleaser, producing `ghcr.io/zincsearch/zincsearch`. Releases are cut by tag with goreleaser, configured in `.goreleaser.yml`, and beta2 specifically tightened that configuration to produce the smallest Go binary it could.

One loose end worth naming: the license field on the repository reads NOASSERTION, while the tree contains both a `LICENSE` file and a separate `COPYRIGHT` file. Two license artifacts in one root with a machine-readable license that identifies nothing means you need to read both files before this goes anywhere commercial.

Editorial conclusion

ZincSearch is a credible answer to a narrow question: can full text search be a Go binary that starts in two minutes and needs no tuning lecture. The README answers yes and then spends real effort delimiting the answer, sending log searchers to OpenObserve and refusing the Kibana claim outright. The 1.0.0-beta1 rewrite on 2026-09-13 reset the internals while keeping the ingest contract, and beta2 and beta3 followed within three days on frontend performance, Go 1.27 CI and a cached-credential eviction bug that matters if you delete users. The license field reads NOASSERTION while the tree carries both LICENSE and COPYRIGHT files, so check which one governs before you put this in a product. If your workload fits the app-search shape the README describes, this is a short evaluation; if it does not, the README already told you so.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. zincsearch/zincsearch on GitHub