Introducing Hanzo Datastore: a post-quantum-ready OLAP engine

Today we ship Hanzo Datastore — the OLAP half of the Hanzo data platform. It is a fork of ClickHouse 26.6, debranded and rebuilt around how we actually run analytics: storage separated from compute on Hanzo S3, a leaner optimized binary, and the legacy RPC surface removed. The image is live at ghcr.io/hanzoai/datastore:26.6.1.1.

We did not write a new database. ClickHouse is the best columnar engine in the world and we stand on it. What we changed is the parts that matter for running a fleet: the storage substrate, the build, the transport, and the coordination roadmap.

Storage and compute, separated

A MergeTree table's parts are immutable objects. Datastore stores them as objects on Hanzo S3 — our SeaweedFS-derived storage layer — instead of on a local disk welded to one server. Stateless compute replicas then share one physical copy of the data through zero-copy replication.

This is proven, not aspirational. In our scale-out test a 5M-row table whose storage policy targets S3 reports disk seaweed in system.parts, and two compute nodes scale out over that single copy. Adding a reader does not copy the data; it attaches to it. That is the property you want when an analytics workload spikes and you need to add query capacity in seconds without reshuffling terabytes.

-- parts live on S3, not on a node's local disk
SELECT name, disk_name FROM system.parts WHERE table = 'events' LIMIT 1;
-- ┌─name──────┬─disk_name─┐
-- │ all_1_1_0 │ seaweed   │
-- └───────────┴───────────┘

Half the memory, a smaller binary

The release build runs profile-guided optimization, thin link-time optimization, and a BOLT post-link pass. The result is roughly half the resident memory of the stock build and a materially smaller binary. Getting BOLT working on aarch64 meant turning off XRay instrumentation, which had been defaulting on and quietly blocking the post-link rewrite — that fix is in the tree. The practical effect: the same query plan, fewer gigabytes, and a binary that starts faster.

gRPC is gone

A datastore should have exactly one query path, not three. We removed the gRPC server entirely — no contrib/grpc, no protobuf service definitions, no ENABLE_GRPC build path — and in the same pass scrubbed the dead <grpc> block out of the default config so the shipped product matches the build. Datastore speaks native TCP (9000), HTTP (8123), and interserver replication (9009). That is the whole surface.

The intended forward transport is ZAP, our Cap'n-Proto-derived RPC. The server stub has landed; it is not yet the live query path. We would rather tell you exactly where that line is than imply it is finished.

Where coordination is headed

Replicated* tables today coordinate through embedded Raft, the ZooKeeper-compatible Keeper that ships inside the server process — no separate daemon. That works and it is what you run in production now.

The direction is to replace that Raft backend with Quasar, the leaderless, post-quantum consensus from Lux, linked natively into the C++ server. The seam is real: a C++ program already drives the native consensus engine through its C ABI — open a chain, append a replication-log entry, drive confidence votes, observe finality — with zero Raft and zero zero-knowledge machinery. That is the proof that the swap is a linking problem, not a rewrite. It is not yet the production coordination layer, and we will not pretend otherwise.

The other half

Datastore is OLAP. The OLTP half of the platform is a decentralized SQL engine built on SQLite/Base — designed, being built, not yet shipped. If you want the local-first, single-file data story today, that lineage already shows up in Hanzo Brain, and the storage substrate both halves ride on is the one we launched in Hanzo Storage.

Run it

docker run -d --name datastore \
  -p 8123:8123 -p 9000:9000 \
  ghcr.io/hanzoai/datastore:26.6.1.1

• Source: github.com/hanzoai/datastore
• Product: hanzo.ai/datastore
• Docs: docs.hanzo.ai

The arm64 image is published now; the amd64 build follows through CI. This is the analytics and insights backend we run ourselves — point your events at it and query them back at columnar speed.