Back to blog
Infrastructure

Working with ZincSearch: A Lightweight Alternative to Elasticsearch

Before ZincSearch, our developers were losing roughly an hour a day to log indexing overhead. Elasticsearch was overkill for what we needed. Here's how ZincSearch solved the problem at a fraction of the resource cost.

September 24, 2023
5 min read

Log management is one of those infrastructure problems that looks simple until it isn't. You need full-text search across large volumes of structured and unstructured log data, ideally with low latency. The obvious choice is Elasticsearch — but reliable Elasticsearch is expensive to run and operationally demanding to maintain.

Why we didn't use Elasticsearch

We considered both Elasticsearch and OpenSearch. Both are excellent — and both are significantly overspecified for a team that primarily needs fast log retrieval, not complex analytics or machine learning. The resource footprint was the deciding factor. A production-grade Elasticsearch cluster requires substantial memory per node, careful JVM tuning, and dedicated operational attention.

We needed something that would run comfortably on modest resources, support Elasticsearch-compatible APIs (so we could reuse existing tooling), and be simple enough that it didn't become its own maintenance burden.

Discovering ZincSearch

ZincSearch is written in Go and built on Bluge, an open-source indexing library. It supports Elasticsearch-compatible APIs, which meant our existing log shippers and dashboards worked without modification. At the time we adopted it, the project was among the fastest-growing on GitHub — a strong signal that others were hitting the same pain point.

Our setup: ZincSearch + FluentBit

We deployed ZincSearch via its Helm chart into our Kubernetes cluster and paired it with FluentBit as the log shipper. FluentBit was chosen specifically for its minimal resource consumption — it runs as a DaemonSet on every node and adds negligible overhead.

bash
helm repo add zinc https://charts.zincsearch.com
helm install zincsearch zinc/zinc \
  --set auth.initialAdminUser=admin \
  --set auth.initialAdminPassword=${ZINC_PASSWORD} \
  --set persistence.enabled=true \
  --set persistence.size=50Gi

Solving the log retention problem

ZincSearch has no built-in log expiration mechanism. Storage filled up faster than expected, and there was no automatic cleanup. We solved this with a custom script deployed as a Kubernetes CronJob, configured to delete log data older than two weeks.

yaml
apiVersion: batch/v1
kind: CronJob
metadata:
  name: zinc-log-cleanup
spec:
  schedule: "0 2 * * *"  # 2am daily
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: cleanup
            image: curlimages/curl:latest
            command:
            - /bin/sh
            - -c
            - |
              # Delete indices older than 14 days
              curl -X DELETE "http://zincsearch:4080/api/index/logs-$(date -d '14 days ago' +%Y.%m.%d)"

Results

The numbers justified the switch. Developers who previously spent roughly an hour daily on log-related tasks saw that time drop dramatically. Resource utilisation across the logging infrastructure decreased by 15%, directly translating to reduced infrastructure costs. Log search that previously required waiting for Elasticsearch to index and respond now returns results in milliseconds.

  • 20% monthly working-hour savings across the engineering team
  • 15% reduction in infrastructure resource utilisation
  • Near-instant log retrieval versus seconds with the previous setup
  • Elasticsearch-compatible APIs — zero changes to existing tooling
  • Minimal operational overhead — no JVM tuning, no complex cluster management
All articles