MooseStack is EOL: hypequery vs Moose for ClickHouse

MooseStack has reached end of life

The decision is no longer between two actively maintained projects. The MooseStack maintainers state that MooseStack has reached end of life and is no longer actively maintained, and GitHub shows the repository as archived and read-only. Read the official MooseStack EOL statement on GitHub.

That means we do not recommend starting a new production analytics backend on MooseStack. Existing users should first decide which parts of Moose they actually need to replace: ClickHouse schema management, streaming ingestion, workflows, typed query APIs, or the agent-facing development harness. hypequery covers the typed ClickHouse query, semantic layer, API, React, and MCP portion; it does not attempt to replace Redpanda, Temporal, or a migration system.

For a step-by-step inventory and mapping, use the MooseStack to hypequery migration guide.

What hypequery replaces

If your Moose application used typed data models and query APIs to power a TypeScript product, hypequery provides the active, narrower path:

• generate TypeScript types from the ClickHouse schema that exists now;
• move reusable analytics into typed datasets, dimensions, measures, and metrics;
• expose those contracts through validated HTTP routes and OpenAPI;
• consume them through typed React hooks;
• expose governed metrics and dataset queries through MCP tools for AI agents;
• enforce multi-tenant scope from trusted runtime context.

The direction of schema ownership changes. Moose was code-first infrastructure: code declared tables and pushed schema into ClickHouse. hypequery is database-first at the physical layer and code-first at the semantic layer: your migration tool owns ClickHouse DDL, the hypequery CLI introspects the live result, and TypeScript owns the product-facing analytics contract.

What hypequery does not replace

hypequery is not a streaming or workflow platform. Keep or choose dedicated tools for:

• Kafka or Redpanda ingestion;
• Temporal workflows and scheduled orchestration;
• ClickHouse DDL migrations;
• infrastructure provisioning and deployment of ClickHouse itself.

This smaller boundary is deliberate. It lets teams migrate the application-facing analytics layer without rebuilding ingestion and infrastructure at the same time.

Current comparison

Migration shape

The safest migration is incremental:

1. Freeze new Moose-specific surface and export the current ClickHouse DDL, tables, and materialized views.
2. Assign schema migrations, ingestion, and workflows to explicit tools outside the application query layer.
3. Generate hypequery types from the live ClickHouse schema.
4. Port one read-only query at a time and compare generated SQL and results.
5. Promote shared calculations into datasets and metrics.
6. Move API consumers to Serve routes, then React hooks or MCP tools.
7. Remove the Moose runtime only after traffic, jobs, and deployment dependencies have been accounted for.

The clients can coexist during the transition, so there is no reason to combine the infrastructure and query migrations into one cutover.

Recommendation

For a new TypeScript application on ClickHouse, use an actively maintained query and semantic layer rather than adopting an archived framework. hypequery is the fit when you already have or want to keep control of ClickHouse and need typed application queries, multi-tenant analytics APIs, React hooks, and MCP tools.

If you need the full infrastructure scope Moose once provided, pair hypequery with the dedicated ingestion, workflow, and migration tools your team is prepared to operate. Start with the migration guide, check the current capability matrix, and test the quick start against one real table.