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 glanceClickHousePhoenix
LicenseApache-2.0Source-available
LanguagesC++, PythonPython, TypeScript
DeploymentSelf-hosted / Runs locally / Managed cloudSelf-hosted / Runs locally / Managed cloud
MaturityEstablishedEstablished
Stars49.3k11.1k
Star growth over the last 7 days+2 ★
Forks8.8k1.1k
Open issues6.9k922
Last commit16 Aug 202615 Aug 2026
ActivityActiveActive

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 callColumnar 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 LangfuseLangfuse 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 databaseA vector_similarity index builds an HNSW graph over Array(Float32), Array(Float64) or Array(BFloat16) columns with L2Distance, cosineDistance or dotProduct, 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 filterPre-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 LIMIT asked for when candidates fail the WHERE clause. 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 MCPClickHouse publishes mcp-clickhouse in a separate repository, exposing list_databases, list_tables and run_query plus a chDB tool for embedded queries. It runs read-only unless CLICKHOUSE_ALLOW_WRITE_ACCESS=true is set, with DROP and TRUNCATE behind a second flag.

Phoenix

  • Instrument an app automaticallynpx @arizeai/phoenix-cli setup (or px setup once Phoenix is installed) detects your framework and LLM provider, installs the matching OpenInference instrumentation and wires up trace export.
  • Run the platform locallyuvx arize-phoenix serve brings 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 callThe 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 experimentsarize-phoenix-evals scores 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 agentThe remote MCP server built into Phoenix exposes a /mcp endpoint that Claude Code, Cursor and other MCP clients can use to read traces, datasets and experiments.

Other comparisons