I built a rust database for agent traces (sub-ms p95 at 1B rows)

Been hacking on agent infra for the last few months and the storage layer kept eating our budget. Sharing what we built to fix it. The pain: agent traces are a weird shape. A trace is long. Hundreds of attributes per span, most of them NULL. Wide JSON payloads in the non-NULL ones (prompts, tool outputs, completions). Evaluator scores arrive weeks later and need to merge in cleanly. The hot query is "show me this whole trace" not "scan a billion rows and aggregate." Postgres, ClickHouse, and DuckDB all degrade on this shape. We benchmarked at 1B spans: \- Postgres: 7.9ms p95 trace fetch \- DuckDB: 3.5 seconds p95 trace fetch \- ClickHouse: 178ms p95 trace fetch \- Ours: 571 microseconds p95 trace fetch The core idea is trace-locality: at compaction time every span of a single trace lands in the same row group, sorted by (trace\_id, start\_time, span\_id). A trace fetch becomes one segment read regardless of how big your dataset is. That's why latency stays flat from 1M to 1B spans. Other design choices: full-text search (Tantivy) embedded inline in the storage segments so there's no sidecar Elasticsearch to keep in sync. WAL on object storage instead of Kafka. Late materialization so wide prompt/completion columns aren't decoded for rows filtered out by other predicates. It's called ZenithDB. Rust, Apache 2.0, alpha. SQL + OTLP ingest. Works with OpenAI Agents SDK, Anthropic SDK, and any OTel-instrumented stack. Curious what storage everyone else is using for agent traces. I've heard a lot of "we're on Postgres jsonb and it's getting slow at scale" stories; wondering if that matches what others are running into.