A columnar database for analytics, written in Zig, that you query with rollup-friendly SQL
Reports over years of events, logs, metrics or sensor readings get slow and expensive as the data grows. muscles keeps the totals a dashboard needs up to date as rows arrive, so a query reads a few summary rows instead of millions, and it queries your existing datalake directly.
Companies that require state-of-the-art query execution on their existing datalakes, or who want to collect petabytes of timestamped data into a highly optimized columnar format
The data may be order events, access logs, Prometheus metrics, meter readings or trades.
Getting data in
Rows arrive from Kafka, from Prometheus remote write, from an agent that tails log files, or from plain inserts. A write is acknowledged after it is synced to disk.
Querying it
muscles accepts a subset of ClickHouse SQL, and ClickHouse drivers can connect over HTTP. The documentation shows how.
Running it
muscles is one static binary. It also comes as a container image, a Helm chart and a Kubernetes operator. It runs on your own servers or in your cloud account. The architecture page shows how the pieces fit together.
What you can do with it
- Keep one-second sensor readings for a week and one-minute rollups for a year.
- Count 5xx responses per route and minute in a materialized view that updates as log lines arrive.
- Match each trade to the quote that was in force at that moment, with an ASOF join.
- Join an Iceberg table in your datalake with a PostgreSQL, MariaDB, ClickHouse or Redis table, and with tables stored in muscles, without copying them.
- Classify support tickets or embed documents from SQL, with a language model that runs on your own network, or with the cloud provider of your choice (OpenAI API-compatible).
- Draw dashboards in Grafana, work in a Python notebook with Polars, or connect with a JDBC driver.
See the features page for examples and planned features.
Control over every byte, so queries run fast
muscles is written in Zig. Zig gives a programmer the same control over the machine as C, without the work that Rust and C++ do behind the scenes. In Rust and C++, containers grow and copy themselves, memory is freed by code that nobody wrote out, and the cost hides inside library code. Zig does none of that on its own. Every byte muscles uses is requested on purpose and returned on purpose.
For an analytical database, that control turns into speed. A query reads millions of values from compressed columns. muscles lays them out in memory the way the processor reads them fastest, and the loops that scan and aggregate them make no hidden copies and no allocations. The same control keeps memory use flat: each query runs inside its own budget and returns all of it when it ends.
So if you use muscles in place of, say, Trino, as a query engine over your existing datalake, you get a smaller memory footprint, faster answers and a lower hardware bill.
We are looking for a few teams to run muscles on their own data and tell us what works and what does not
You can test it for 30 days at no cost, with our help. If it works for you, you buy a licence at a reduced beta rate.
Beta terms are agreed in a contract before onboarding. Read how the beta works or write to hello@muscles.dev.