You can now model ClickHouse Buffer engines in MooseOLAP TypeScript and Python projects.
import { ClickHouseEngines, Key, OlapTable } from "@514labs/moose-lib"; interface PaymentEvent { eventId: Key<string>; amount: number; capturedAt: Date;} export const paymentBuffer = new OlapTable<PaymentEvent>("payment_buffer", { engine: ClickHouseEngines.Buffer, targetDatabase: "analytics", targetTable: "payment_events_local", minRows: 5_000, maxRows: 500_000,});PR: #2908 | Docs: Buffer engine | ClickHouse Buffer engine docs
You can now model ClickHouse S3 engines in MooseOLAP TypeScript and Python projects. The CLI serializes engine settings, resolves runtime credentials, and enforces the S3 rule set (PARTITION BY allowed, ORDER BY rejected) so you can read or write datasets that live entirely in S3.
import { ClickHouseEngines, OlapTable } from "@514labs/moose-lib"; interface ArchivedOrder { orderId: string; status: string; processedAt: Date;} export const archivedOrders = new OlapTable<ArchivedOrder>("archived_orders", { engine: ClickHouseEngines.S3, path: "s3://company-archive/orders/{yyyy}/{MM}/", format: "Parquet",});PR: #2908 | Docs: S3 engine | ClickHouse S3 docs
Beta (self-hosted only): Not supported on Boreal or ClickHouse Cloud. You can now model ClickHouse Distributed engines in MooseOLAP TypeScript and Python projects. Plans capture the cluster, target database/table, and optional sharding key, while validation checks that the referenced local tables exist on every node before executing migrations.
import { ClickHouseEngines, Key, OlapTable } from "@514labs/moose-lib"; interface UserEvent { userId: Key<string>; eventType: string; occurredAt: Date;} export const userEventsDistributed = new OlapTable<UserEvent>("user_events_distributed", { engine: ClickHouseEngines.Distributed, cluster: "analytics_cluster", targetDatabase: "analytics", targetTable: "user_events_local", shardingKey: "cityHash64(userId)",});PR: #2908 | Docs: Distributed engine | ClickHouse Distributed docs
moose generate migration and moose migrate accept a Redis URL (flag or MOOSE_REDIS_CONFIG__URL) whenever state_config.storage = "redis". The CLI resolves ClickHouse + Redis endpoints, acquires migration locks in Redis, and reuses the same builder across serverless tooling.
export MOOSE_CLICKHOUSE_CONFIG__URL="https://user:pass@ch.serverless.dev/main"
export MOOSE_REDIS_CONFIG__URL="redis://redis.example.com:6379"
moose migrate --clickhouse-url "$MOOSE_CLICKHOUSE_CONFIG__URL" --redis-url "$MOOSE_REDIS_CONFIG__URL"PR: #2907 | Docs: Redis state storage
Tables now carry a database field through the CLI, codegen, and infrastructure map. Moose will create any additional_databases, validate plans that attempt to move an existing table, and surface fully qualified names in moose ls.
import { Key, OlapTable } from "@514labs/moose-lib"; interface AuditLog { id: Key<string>; recordedAt: Date; message: string;} export const auditLogs = new OlapTable<AuditLog>("audit_logs", { database: "operations", orderByFields: ["recordedAt", "id"],});PR: #2876 | Docs: Multi-database setup
moose migrate flow with env-var overrides for CI/CD. Docs: Redis state storage | PR #2907database overrides, auto-creates configured databases, and blocks accidental moves between them. Docs: Multi-database setup | PR #2876flake.nix now bootstraps a full MooseStack build environment (nix develop drops you into a development shell that will have everything you need to build all the components of moosestack). If you use Nix, let us know!
Give it a go if you have nix installed on your machine with:
nix run github:514-labs/moosestack # -- to pass additional arguments to the cliPR: #2920