Ochi is a cost-effective, Loki compatible, database for logs.

_{Ochi (pronounced oh-chee) translates to "Eyes" in various Slavic languages.}

Introduction

We are creating a more efficient alternative for storing logs.

Install

Download pre-built binary

VERSION=v0.6.7 &&
curl -Ls "https://github.com/ochi-team/ochi/releases/download/${VERSION}/Ochi-${VERSION}-linux-x86_64.tar.gz" | tar -xz

Build from source

• install zig 0.16.0
• compile with zig build -Doptimize=ReleaseSafe -Drelease=true

Documentation

https://ochi.dev/docs/guides/installation/

Roadmap

• store persists the data, working simple API queries
• Grafana datasource available
• home made query language
• installation scripts
• Ochi starts emitting logs to itself, dogfooding Ochi
• Home made UI
• Disk snapshots and recovery
• Replication to a secondary mount
• aarch64 release target
• full support of Loki ingestion protocol (snappy, zstd, protobuf encoding, etc.)
• docker-compose with configured datasource to grafana
• OTEL collector API support
• configuration support
• windows devevlopment support
• cost analysis
• GDPR compliance

Goals

• support aarch64 and x86_64 as Tier 1
• support Windows and POSIX systems for development
• support only Linux for production workloads (community is free to do whatever)
• better core over features

Non goals

• support every OS
• "feature completeness"

Contributing

Ochi is being actively developed by a small team of engineers (team of 1).

Open an issue before submitting a PR. Although bug fixes are exceptions, but they must be provided with a test to demonstrate a bug.

Optimization improvements are welcome, but must be accompanied by a benchmark.

Before submitting a PR, make sure the tests pass:

# for short iterations
zig build test
# or specific target
zig build test -Dtest-filter="flushForce clears merge flags"
# or full run
zig build test -Dallocation-failures=true

For all questions, major changes, suggestions, notes, feel free to reach out to the team on Discord.

AI Policy

1. We don't shame the lack of knowledge, it's better to accept not knowing, than spreading disinformation.
2. Using LLMs you put your trust profile on a line, we don't encourage it, but you may.
3. Complete slop will be rejected with no comment and a permanent ban.
4. We can invest our time helping you to learn. Don't rely fully on LLMs to implement a solution.
5. You can generate a test that is able to crash the system, however if the test crashes itself, not the system, it's defined as a slop, read point 3.

Code style

• a good inner function comment describes why, not what
• a good outer function comment (doc string) describes what
• explicit is better than implicit
• therefore default options are not the best
• tests must either cover data or effects, not both
• to produce effect it must take a data to produce a pre determined effect
• pure functions are welcome
• allocations first, mutating after