Chegou o Hanzo Datastore: um motor OLAP pronto para o pós-quântico
Um armazém colunar derivado do ClickHouse, reconstruído em torno da separação entre armazenamento e computação no Hanzo S3, otimizado por perfil e em tempo de link até cerca de metade da memória, sem gRPC e com um caminho para a coordenação pós-quântica sem líder.

Nesta página
Hoje lançamos o Hanzo Datastore — a metade OLAP da plataforma de dados de Hanzo. É um fork do ClickHouse 26.6, sem a marca de origem e reconstruído em torno de como realmente rodamos a análise: armazenamento separado da computação no Hanzo S3, um binário otimizado mais enxuto e a superfície RPC antiga removida. A imagem já está no ar em ghcr.io/hanzoai/datastore:26.6.1.1.
Não escrevemos um banco de dados novo. O ClickHouse é o melhor motor colunar do mundo e nos apoiamos nele. O que mudamos são as partes que importam para rodar uma frota: o substrato de armazenamento, o build, o transporte e o roteiro da coordenação.
Armazenamento e computação, separados
As partes de uma tabela MergeTree são objetos imutáveis. O Datastore as guarda como objetos no Hanzo S3 — nossa camada de armazenamento derivada do SeaweedFS — em vez de um disco local soldado a um servidor. Réplicas de computação sem estado compartilham então uma única cópia física dos dados por replicação zero-copy.
Isso está provado, não é uma aspiração. No nosso teste de scale-out, uma tabela de 5 milhões de linhas cuja política de armazenamento aponta para S3 informa o disco seaweed em system.parts, e dois nós de computação escalam sobre essa única cópia. Adicionar um nó de leitura não copia os dados; ele se acopla a eles. Essa é a propriedade que você quer quando uma carga analítica dispara e você precisa somar capacidade de consulta em segundos, sem remexer 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 │
-- └───────────┴───────────┘
Metade da memória, um binário menor
O build de release roda otimização guiada por perfil, otimização enxuta em tempo de link e uma passagem BOLT depois do link. O resultado é cerca de metade da memória residente do build padrão e um binário bem menor. Fazer o BOLT funcionar em aarch64 exigiu desligar a instrumentação XRay, que vinha ligada por padrão e bloqueava em silêncio a reescrita pós-link — essa correção está na árvore. O efeito prático: o mesmo plano de consulta, menos gigabytes e um binário que sobe mais rápido.
O gRPC saiu
Um datastore deve ter exatamente um caminho de consulta, não três. Removemos o servidor gRPC por completo — sem contrib/grpc, sem definições de serviço protobuf, sem caminho de build ENABLE_GRPC — e na mesma passagem limpamos o bloco <grpc> morto da configuração padrão, para que o produto entregue combine com o build. O Datastore fala TCP nativo (9000), HTTP (8123) e replicação entre servidores (9009). Essa é toda a superfície.
O transporte daqui para a frente é ZAP, nosso RPC derivado do Cap'n Proto. O stub do servidor já chegou; ainda não é o caminho de consulta ao vivo. Preferimos dizer exatamente onde essa linha está, em vez de insinuar que está pronta.
Para onde a coordenação caminha
As tabelas Replicated* hoje se coordenam por Raft embutido, o Keeper compatível com ZooKeeper que vem dentro do processo do servidor — sem um daemon separado. Isso funciona, e é o que você roda em produção agora.
A direção é trocar esse backend Raft pelo Quasar, o consenso sem líder e pós-quântico do Lux, ligado de forma nativa no servidor C++. A junção é real: um programa C++ já conduz o motor de consenso nativo pela sua C ABI — abrir uma cadeia, anexar uma entrada do log de replicação, conduzir votos de confiança, observar a finalidade — com zero Raft e zero maquinaria de zero-knowledge. Essa é a prova de que a troca é um problema de linking, não uma reescrita. Ainda não é a camada de coordenação de produção, e não vamos fingir o contrário.
A outra metade
Datastore é OLAP. A metade OLTP da plataforma é um motor SQL descentralizado construído sobre SQLite/Base — desenhado, em construção, ainda sem lançamento. Se você quer hoje a história de dados local-first e de um único arquivo, essa linhagem já aparece em Hanzo Brain, e o substrato de armazenamento em que as duas metades rodam é o que lançamos em Hanzo Storage.
Rode
docker run -d --name datastore \
-p 8123:8123 -p 9000:9000 \
ghcr.io/hanzoai/datastore:26.6.1.1
- Código: github.com/hanzoai/datastore
- Produto: hanzo.ai/datastore
- Docs: docs.hanzo.ai
A imagem arm64 está publicada agora; o build amd64 vem em seguida pela CI. Este é o backend de análise e insights que nós mesmos rodamos — aponte seus eventos para ele e consulte-os de volta em velocidade colunar.
Leia mais

Acabando com o Raft: do consenso ZooKeeper ao Lux Quasar, nativo
Como o Hanzo Datastore troca o motor NuRaft sob o ClickHouse Keeper pelo Lux Quasar — consenso pós-quântico e sem líder, ligado direto no servidor C++ — e mantém a API ZooKeeper que a replicação fala.

Hanzo Insights: Product Analytics That Respects Privacy
Introducing Hanzo Insights — product analytics with event tracking, funnels, cohorts, and session replay, without selling user data.

Hanzo Storage: S3-Compatible Object Storage
Launching Hanzo Storage — S3-compatible object storage with integrated CDN and no egress fees.