zeekayandHanzo Dev
8ca48ae27a
The S3 engine and table-function docs handed readers `'minioadmin', 'minioadminpassword'` five times as the way to authenticate, plus the integration fixture's own `ClickHouse_Minio_P@ssw0rd` in the s3Cluster examples. Copy-pasteable weak credentials in the reference docs are a worse problem than the branding: they get pasted. Those are placeholders now, and the endpoints point at Hanzo S3 (`hanzoai/s3` — SeaweedFS-derived, Apache-2.0, and never a MinIO fork). `registerStorageObjectStorage.cpp` also linked a docker-compose recipe at github.com/Datastore/examples, a URL the ClickHouse->Datastore rebrand invented and that has never resolved. The sentence no longer depends on it. Scope is deliberately docs only, both copies of them: `docs/en/**` — the one doc tree `docs/AGENTS.md` says to edit — and the `src/**` `R"DOCS_MD(...)"` blocks that mirror it into the binary. Every changed line in a .cpp is inside a documentation raw-string (verified by delimiter-span check, 21/21); the only header change is a `///` comment. No executable code, no test, no fixture, no build config. The integration-test harness keeps MinIO on purpose, and LLM.md now records why so this is not re-litigated or sed'd: `minio==7.2.20` is a real dependency behind `from minio import Minio` in helpers/cluster.py, 60 test files call 16 distinct client methods, 136 tests pass with_minio=True, ~120 storage XMLs hardcode the fixture credential, and the compose file leans on MinIO-only surface (--certs-dir TLS, prometheus auth mode, console address, virtual-host bucket aliases) fronted by a registry-pulled clickhouse/s3-proxy image. That port is a real project whose acceptance test is the S3 suite going green, and it cannot be run here: ghcr.io/hanzoai/s3 is linux/amd64 only and this is arm64. Co-authored-by: Hanzo Dev <[email protected]>
Hanzo Datastore is a column-oriented database for real-time analytical queries.
What it is
Datastore is the OLAP half of Hanzo's data platform. It is a fork of ClickHouse, narrowed to one job and rebuilt around separated storage and compute.
MergeTree parts are stored as objects on Hanzo S3,
so stateless compute replicas share a single zero-copy copy of the data instead of
each carrying its own. Scaling out adds query capacity without adding storage.
Run
The published image is ghcr.io/hanzoai/datastore, built multi-arch by CI from
docker/server/Dockerfile.ubuntu.
cd hanzo && docker compose up
Debian and RPM packages are built from packages/ — datastore-server,
datastore-client and datastore-common-static.
Connect
| Port | Protocol | Purpose |
|---|---|---|
| 9000 | TCP | native binary protocol — the live query path |
| 8123 | HTTP | HTTP interface |
| 9009 | TCP | interserver replication |
| 9181 | TCP | embedded coordination client port |
HTTP requests authenticate with X-Datastore-User and X-Datastore-Key, or with
HTTP Basic, or with ?user= and ?password= query parameters. The server also
returns X-Datastore-Query-Id, X-Datastore-Format, X-Datastore-Summary and
X-Datastore-Exception-Code.
curl -H 'X-Datastore-User: default' -H 'X-Datastore-Key: ' \
--data 'SELECT version()' http://localhost:8123/
How it differs from upstream
One binary. datastore is the only server binary. Coordination runs in-process
whenever <keeper_server> is present in the config — there is no separate keeper
process to deploy.
OLAP only. External stream brokers and foreign-database read/CDC engines are
disabled at build time: Kafka, RabbitMQ, MySQL, PostgreSQL, MongoDB, HDFS, Hive,
Cassandra, YTsaurus. Their source trees remain behind USE_* macros so upstream
merges stay clean. MergeTree and its replicated and distributed variants, S3,
ObjectStorage, File, URL, Memory, Log, views, RocksDB and dictionaries
are kept.
No gRPC, no Arrow Flight. Both RPC surfaces are removed. The replacement transport is ZAP, a Cap'n-Proto-derived RPC; its server stub has landed but is not yet the query path.
Coordination is moving off Raft. The ZooKeeper API stays — it is the contract that replicated tables speak — while the engine underneath is being replaced with Quasar, which is post-quantum and leaderless. The engine is proven single-node and tested; the multi-node cutover is in progress.
Performance
ClickBench, 43 queries against the 100M-row hits dataset, aarch64, 4 runs per
query, warm cache. Compared against the official ClickHouse binary:
| Metric | ClickHouse | Datastore | Delta |
|---|---|---|---|
| Peak RSS under load | 14.52 GB | 13.96 GB | −3.8% |
| Total query time | 16.83 s | 16.82 s | tied |
| Per-query | — | faster on 8 of 43 | ~neutral |
Read that honestly: at production scale the build buys about 4% less peak memory and is statistically tied on speed. An earlier "half the memory, much faster" figure was real but measured at 10M rows, where a leaner binary is a large share of a small working set; at 100M rows the data dominates and the same fixed saving shrinks. Never quote the 10M number without its scale. The 100M run is one workload on one machine with per-query noise around ±25%, so "tied" is within noise. The fork's value is architectural, not raw speed over stock.
Upstream
Upstream is ClickHouse/ClickHouse. A
scheduled workflow merges upstream/master into a dated branch weekly and opens a
draft pull request; it never auto-merges, and a conflicted merge is pushed with
markers intact and labelled. Net-new Hanzo files live under hanzo/, disjoint from
upstream, so most syncs land clean.
Links
- hanzo.ai — Hanzo AI
- docs.hanzo.ai — documentation
- hanzo.ai/blog — announcements
License
Apache-2.0. Forked from ClickHouse at v26.6.1.1, Copyright 2016-2026 ClickHouse, Inc. See NOTICE for attribution and the full list of deviations from upstream.