Langfuse vs Opik vs Arize Phoenix

Langfuse, Opik and Phoenix all keep traces in your own infrastructure, but they differ sharply in how many stateful services you run to do it. A self-hosted Langfuse deployment runs two application containers, Langfuse Web and Langfuse Worker, backed by PostgreSQL, ClickHouse, Redis or Valkey and S3-compatible blob storage. Opik runs on ClickHouse, MySQL and Redis, with its application services on top. Phoenix starts with a file-based SQLite database by default and can use PostgreSQL through PHOENIX_SQL_DATABASE_URL or separate connection variables. The practical question is not which store is fastest, but how many engines your team must patch, monitor, back up and restore.

For backup, each store needs its own plan. In Langfuse, PostgreSQL holds transactional data while ClickHouse holds the analytical event data, and blob storage holds uploaded objects, so a restore test must cover all three, and the Redis or Valkey layer is generally treated as queue and cache state. Opik's split between ClickHouse and MySQL works the same way. A single SQLite file in Phoenix is the simplest to copy, but it is a single writer on one host, so moving to PostgreSQL is the usual step once more than one person or service depends on it. Confirm the backup tooling, retention and point-in-time recovery options for each engine with your DBA and with each vendor's documentation before you commit.

Scaling follows the storage choice. Langfuse's scaling guide lists minimum resources for each component, including 2 CPU and 8 GiB for ClickHouse and at least 16 GiB of ClickHouse memory for larger deployments, and recommends scaling worker containers on CPU load. Opik's README states it handles 40M+ traces per day, which is the only throughput figure we can cite for it, so you should run a load test that reflects your own trace volume rather than assume that number applies to your workload. Phoenix's SQLite default suits local work, while a PostgreSQL-backed Phoenix still runs as a single service, so plan for that before you treat it as production-scale. Ask each vendor for sizing guidance that matches your expected ingestion rate and retention window.

The instrumentation layer decides how much of your tracing code is tied to one vendor, so check it before you pick a tool. All three platforms accept OpenTelemetry in some form, but they differ in how they get there. Opik supports OpenTelemetry and also ships native integrations with LangChain, LangGraph, LlamaIndex, CrewAI and 60+ other frameworks, plus a @track decorator for custom code. Phoenix is built on OpenTelemetry with OpenInference semantic conventions, and its README says the same instrumentation works with both Phoenix and the managed Arize AX platform. Langfuse publishes its own OpenTelemetry documentation and its SDKs sit on the same standard. If your stack already emits OpenTelemetry spans, confirm each tool's ingestion path for those spans before you write any vendor-specific code.

The lock-in risk comes from the layer you write into most often. A decorator or framework callback that only one platform understands means every traced function carries that platform's API, and moving later means rewriting those call sites. Plain OpenTelemetry exporters keep the span format in your hands, so switching backends mostly changes an exporter endpoint and a collector configuration. OpenInference adds attribute conventions for LLM calls, retrievals and tools on top of OpenTelemetry, so confirm whether a given tool reads those attributes natively or needs a mapping. Phoenix's statement that the same instrumentation runs against Arize AX is useful evidence of portability, but it does not show that the reverse path, from Arize AX to your own store, is equally simple. Ask each vendor for a written export path.

To keep traces portable, route application telemetry through an OpenTelemetry Collector that you operate, and point exporters at the observability backend rather than calling vendor SDK methods from business logic. Keep prompts, model names and token counts in standard span attributes where possible, and wrap any vendor-only decorator in one internal module so the rest of the codebase never imports it directly. Run a test in a non-production environment: send the same traces to two backends for a few weeks and compare what each one displays. Record the attribute names your team depends on in a short internal schema. That schema, and not the vendor's dashboard, becomes the reference you carry into any future migration.

Trace data lives in each platform's own stores, so the cost of leaving is mostly the cost of moving history. Langfuse keeps traces in ClickHouse with PostgreSQL for transactional data and blob storage for events, Opik keeps its data in ClickHouse, MySQL and Redis, and Phoenix defaults to a file-based SQLite database and can use PostgreSQL. Switching does not carry over years of traces automatically, and the schemas differ. Before committing, ask each vendor and your own platform team what export paths exist (bulk trace export, API pagination limits, database-level dumps) and how long a full export takes at your current volume.

Instrumentation is where switching can be cheap. Opik supports OpenTelemetry and has native integrations with LangChain, LangGraph, LlamaIndex and CrewAI, and Langfuse documents an OpenTelemetry path. Phoenix uses OpenInference instrumentation, and its README says the same OpenTelemetry and OpenInference instrumentation works with both Phoenix and Arize's managed platform. Teams that have instrumented with OpenTelemetry directly and kept vendor SDK calls out of application logic can usually repoint an exporter. Teams using the Opik @track decorator or a vendor SDK wrapper should expect to edit those call sites and test span structure again.

Evaluations, prompts and datasets are the part most likely to fail a one-to-one migration. Judge prompts, scoring rules, online evaluation rules, prompt versions and labels, and versioned datasets are defined inside each product's model, so they often need to be rebuilt by hand. Confirm with each vendor whether prompts, datasets and experiment results can be exported in a usable format, and keep your own copy of evaluation definitions in version control. Also check the feature gating on your target edition: Langfuse keeps items such as data retention policies and audit logs behind an Enterprise license key, so a team that relied on them may find those controls missing after a move.