An artist files a ticket: "Blender crashed while I was sculpting." No .blend, no repro steps, no idea which add-ons were running. You try to reproduce it, fail, and close it cannot reproduce. Every team that supports a DCC tool knows this loop.
The full Micromegas stack — ingestion, analytics, maintenance, web UI — now fits in a free-tier VM. One binary, one Postgres, one object store. That's it.
This is the micromegas-monolith: a single process that runs all four roles on one tokio runtime, sharing a data-lake connection, a cache, and a SIGTERM fanout. Spin it up on a free-tier VM, your laptop, or whatever throwaway instance your cloud provider gives away. Point your instrumented app at it. Get logs, metrics, and traces with a full SQL query interface and a web UI, for essentially zero running cost.
That's the pitch for personal telemetry. For teams it's also the fastest demo path: one compose file, no orchestration.
Micromegas's native instrumentation — a Rust crate and an Unreal Engine plugin — gives you about 20ns per event and 100k events per second per process. It's the cheapest way to get telemetry out of code you control. The hard part is "code you control" — production systems are full of code you can't recompile.
Apache DataFusion already supports compiling to WebAssembly — so we took advantage of it. Full SQL running client-side, the same query engine that powers the Micromegas backend, now running in a browser tab. And it scales your analytics compute for free.
The most basic stability statistic is Mean Time Between Failures, and your crash reporting service can't tell you what it is. Here's why, and how unified telemetry fixes it with a single SQL query.
With the latest release of Micromegas I'm doubling down on FlightSQL. Not only does it power the connection with Grafana, it will also be the protocol under the Python API.