ClickHouse vs Phoenix
Both are catalogued under Observability & Evals. The figures come from the GitHub API; the assessments are ours.
At a glance
| At a glance | ClickHouse | Phoenix |
|---|---|---|
| License | Apache-2.0 | Source-available |
| Languages | C++, Python | Python, TypeScript |
| Deployment | Self-hosted / Runs locally / Managed cloud | Self-hosted / Runs locally / Managed cloud |
| Maturity | Established | Established |
| Stars | 49.3k | 11.1k |
| Star growth over the last 7 days | — | +2 ★ |
| Forks | 8.8k | 1.1k |
| Open issues | 6.9k | 922 |
| Last commit | 16 Aug 2026 | 15 Aug 2026 |
| Activity | Active | Active |
What each one does
ClickHouse
A column-oriented engine for append-heavy, high-cardinality data, which is the shape agent telemetry takes: one row per model call, filtered later by model, cost or error. Langfuse moved its traces here from Postgres in December 2024 and ClickHouse acquired the project in January 2026, so a self-hosted observability stack increasingly means running this underneath. It is the wrong choice for anything transactional — updates and deletes rewrite whole column parts rather than edit rows — so treat it as where agent runs land, not as the database your application writes state to.
Full entry →Phoenix
Built on OpenTelemetry, so traces are portable rather than locked to one vendor, and it will run locally next to the code you are debugging. Licensed under Elastic 2.0 — fine for internal use, restrictive if you intend to offer it as a managed service.
Full entry →What you can do
ClickHouse
- Store one row per model call — Columnar storage means a query filtering observations by model, cost or error status reads only those columns while multi-megabyte prompt and completion payloads stay on disk, and the engine is built for large batch inserts merged in the background rather than single-row writes — which is how a queued trace ingestion pipeline wants to write.
- Inherit the storage layer under Langfuse — Langfuse moved tracing data out of Postgres into ClickHouse in December 2024, and ClickHouse acquired Langfuse on 16 January 2026, saying the core stays MIT-licensed and self-hostable at production scale. ClickStack, its OpenTelemetry-native observability stack, runs on the same engine.
- Search embeddings without a second database — A
vector_similarityindex builds an HNSW graph overArray(Float32),Array(Float64)orArray(BFloat16)columns withL2Distance,cosineDistanceordotProduct, available from version 25.8. The index has to be loaded from disk into memory in full to serve a search, and building it slows inserts and merges. - Expect exact scans once you filter — Pre-filtering by metadata is, in the documentation's own words, an unsolved problem — ClickHouse falls back to exact nearest-neighbour search — and post-filtering can return fewer rows than the
LIMITasked for when candidates fail theWHEREclause. If narrow metadata filters over a large collection are your main access pattern, a dedicated vector store handles it better. - Let an agent query it over MCP — ClickHouse publishes
mcp-clickhousein a separate repository, exposinglist_databases,list_tablesandrun_queryplus a chDB tool for embedded queries. It runs read-only unlessCLICKHOUSE_ALLOW_WRITE_ACCESS=trueis set, withDROPandTRUNCATEbehind a second flag.
Phoenix
- Instrument an app automatically —
npx @arizeai/phoenix-cli setup(orpx setuponce Phoenix is installed) detects your framework and LLM provider, installs the matching OpenInference instrumentation and wires up trace export. - Run the platform locally —
uvx arize-phoenix servebrings up the full platform with nothing installed, and the same build ships as a Docker Hub image and a Helm chart for cluster deployment. - Replay a captured LLM call — The Playground reruns a traced call with a different prompt, model or parameters, and prompt management keeps those changes under version control with tagging.
- Measure changes as experiments —
arize-phoenix-evalsscores response and retrieval quality against versioned datasets, so a prompt or retrieval change is compared as a tracked experiment rather than by eye. - Query traces from a coding agent — The remote MCP server built into Phoenix exposes a
/mcpendpoint that Claude Code, Cursor and other MCP clients can use to read traces, datasets and experiments.