Arize vs Langfuse: when each option fits
If you are weighing Arize AX against self-hosted Langfuse, the decision usually comes down to who should operate the data plane and how much trace volume and retention you need to keep. Arize AX fits teams that want a managed enterprise platform, vendor support and existing Arize workflows, and that accept span allowances and retention set by their plan. Self-hosted Langfuse fits teams that need traces, prompts and scores to stay in their own cloud accounts or data centers, and that can run the stack themselves. Arize also offers a self-hosted AX option on Kubernetes, which you should price and scope separately before comparing.
Arize AX is the stronger choice when your team wants managed operations, enterprise support and continuity with Arize tracing, datasets and evaluations already in use. Langfuse is the stronger choice when data residency or internal policy requires that traces stay in infrastructure you control. The core Langfuse features are MIT licensed, and the self-hosting docs state that self-hosted deployments run the same codebase as Langfuse Cloud. Some governance features, such as project-level RBAC, audit logs, data retention policies and SCIM, need an enterprise license key, so confirm which of your requirements fall into that set. Your team also needs to run PostgreSQL, ClickHouse, Redis or Valkey, and S3-compatible storage, plus upgrades and backups, which is operating work that Arize AX does not hand to you.
Four factors should decide the choice. Trace volume drives both Arize span pricing and ClickHouse sizing, so estimate your monthly spans and request written allowances from Arize. Retention decides how much history you keep and how much disk you provision. Residency decides whether a hosted region is acceptable at all. SSO needs decide whether you require SAML or SCIM from the open-source core or the enterprise key. Operating capacity is the last check: if no one on your team can own ClickHouse and Postgres upgrades on a fixed schedule, plan for a support arrangement before you migrate.
Which option fits which scenario
This table maps common buyer situations to the option that usually fits better and the condition that makes the difference. Read each row against your own volumes, residency rules and team capacity, then confirm the open items with Arize and Langfuse in writing. The main takeaway is that self-hosted Langfuse shifts cost and operations onto your team, so it fits best when you can staff those components.
| Buyer scenario | Better fit | When it matters |
|---|---|---|
| Span-based cost pressure | Self-hosted Langfuse | Costs scale with your own storage and compute. Confirm current Arize AX span allowances and overage terms in your contract first. |
| Strict data residency in your own network | Self-hosted Langfuse | Traces, prompts and blobs stay in your cloud account or data center. Arize AX self-hosting runs on Kubernetes under its own deployment terms. |
| Enterprise SSO on day one | Arize AX, if its plan includes your SSO | Langfuse SSO and SCIM depend on the enterprise license key. Confirm the exact SSO protocols each tier supports. |
| Small team with no platform engineers | Hosted Arize AX or Langfuse Cloud | Self-hosting means operating PostgreSQL, ClickHouse, Redis or Valkey, blob storage and upgrades. Staff this before choosing self-hosting. |
| Existing OpenTelemetry instrumentation | Either, with a short exporter check | Both accept OpenTelemetry-based traces. Verify your SDK and exporter path against each vendor's current documentation. |
| OSI-approved license required for the self-hosted core | Self-hosted Langfuse | The core is MIT licensed, but enterprise directories and license-key features are separately licensed. Confirm which features you need. |
| Team already runs ClickHouse and PostgreSQL | Self-hosted Langfuse | Existing database skills lower the operating load. ClickHouse sizing and disk headroom still need planning before go-live. |
| Deep evaluation and dataset workflows needed now | Arize AX, pending a feature check | Map your evaluators, datasets and experiments feature by feature against Langfuse before deciding. |
How tracing and evaluation depth compare
Both products collect LLM traces, and the instrumentation path is the first thing to check. Arize AX and Phoenix share OpenTelemetry and OpenInference instrumentation, so teams already using those conventions keep their span definitions. Langfuse supports OpenTelemetry ingestion, so an application that exports OTel spans can be pointed at Langfuse, but attribute mapping for LLM-specific fields should be tested on real traces.
- Instrumentation: Arize AX and Phoenix use OpenInference semantics on top of OpenTelemetry. Langfuse accepts OTel spans through its ingestion path, so confirm which attributes it maps to its own trace and observation fields.
- Span hierarchy: Check that nested agent steps, tool calls and retrieval spans appear in the trace view the way your engineers expect.
- Storage model: In self-hosted Langfuse, trace volume is bounded by the ClickHouse disk and memory you provision and the retention you configure.
- Collector path: The OpenTelemetry Collector can receive spans and forward them to more than one backend, which helps during a parallel-run migration.
- Ingestion limits: Confirm any per-plan ingestion or span limits with Arize, since they are contract terms rather than properties of the software.
Check the current ingestion endpoints, supported attributes and any span limits against the Langfuse OpenTelemetry documentation and Arize's own docs before you plan exporter changes.
Evaluation is where the two products differ most in workflow shape. Langfuse supports LLM-as-a-judge evaluators and annotation queues, which let reviewers score traces by hand alongside automated scoring. Arize AX offers evaluation workflows on traces and experiments, and Phoenix ships its own LLM-based evaluators built on the same instrumentation. Your evaluator templates, judge models and human review steps should drive the comparison, not the feature list alone.
- LLM-as-a-judge: Langfuse runs model-based evaluators against traces. Confirm which judge models you can use in your environment, since the judge calls leave your application and reach a model endpoint you select.
- Annotation queues: Langfuse annotation queues support human scoring of traces. Check whether your review process needs reviewer assignment, rubrics or agreement tracking, and whether those are included in the version you deploy.
- Arize evaluations: Confirm which online and offline evaluation options your AX plan includes and how they attach to traces and experiments.
- Custom scoring: Code-based evaluators that run in your own pipeline and post scores through an API are usually portable, but the score names and data types must be mapped.
- Score history: Historical scores are often the hardest data to move, so decide early whether you need them in the new system.
Confirm evaluator and annotation parity for your specific workflows with each vendor's current documentation and a trial run on a sample of your traces.
Datasets and experiments turn production traces into repeatable tests. In both products, teams typically select representative traces, store them as a dataset, and run a prompt, model or pipeline version against that dataset to compare results. Arize AX and Phoenix include datasets and experiments in the same OpenTelemetry-based workflow. Langfuse provides datasets and experiment runs, but the exact experiment comparison views and dataset versioning behavior should be checked against your current release.
- Dataset creation: Confirm how each product builds datasets from traces, including whether you can select spans, add expected outputs and tag items.
- Experiment comparison: Check how runs are compared side by side and whether scores from different evaluators can be viewed together.
- Versioning: Find out how dataset changes are tracked over time, since an experiment is only reproducible if its dataset version is fixed.
- Pipeline integration: Confirm the SDK or API calls your CI jobs need to create experiment runs and read results.
- Migration effort: Datasets do not usually move automatically between products, so budget engineering time to export items and recreate them, and decide which historical experiments you need to keep.
Ask each vendor to demonstrate an experiment on a dataset you supply, because the dataset workflow is often where teams discover gaps in their own process.
Prompt management connects prompt versions to the traces and experiments that used them. Arize AX includes prompt management and a playground for testing prompts, and Phoenix provides built-in prompt management as part of the open tool. Langfuse supports prompt versions and labels, so teams can promote a version to production by label. Some Langfuse controls, such as protected prompt labels, need an enterprise license key in self-hosted deployments.
- Versioning: Confirm how each product stores prompt versions and whether a trace records the exact version it used.
- Labels and promotion: In Langfuse, labels let applications request a specific environment version. Check how Arize handles promotion and rollback.
- Protected labels: In self-hosted Langfuse, protected prompt labels require an enterprise license key. Include that in your cost comparison if your change control depends on them.
- Playground: Confirm which models, parameters and tool definitions the playground supports in each product, and whether runs from the playground are saved as traces.
- Traceability: Keep prompt versions linked to traces and experiments after the move, or your regression history will be incomplete.
Review the Langfuse license key documentation to see which prompt features require a key, and confirm playground behavior with Arize's current documentation.
Capability comparison from documented facts
This table compares Arize AX and self-hosted Langfuse on the capabilities where the documented facts are specific enough to act on. Where a cell says to confirm, the vendor has not given us a documented answer for that row, so check it in writing before you choose. The main takeaway is that Langfuse's self-hosted core is MIT licensed, while several enterprise controls sit behind a license key.
| Capability | Arize AX | Langfuse (self-hosted) |
|---|---|---|
| Tracing standard | Built on OpenTelemetry and OpenInference, the same standards as Phoenix | Documents an OpenTelemetry integration; confirm which OpenInference attributes it maps |
| Instrumentation | Same OpenTelemetry and OpenInference instrumentation used across Arize products | Langfuse SDKs and OpenTelemetry endpoints; confirm framework coverage for your stack |
| Evaluation approach | Confirm evaluators, datasets and experiments available on your Arize plan | Core features and APIs are in the MIT edition without limits; confirm evaluation features in that edition |
| Prompt management | Confirm prompt versioning and playground features with Arize | Prompt versions are core; protected prompt labels require an Enterprise license key |
| SSO and SCIM | Confirm SSO and SCIM support on your Arize plan in writing | SSO is documented; the org management API with SCIM requires an Enterprise license key |
| Hosting models | Managed cloud, or self-hosted on Kubernetes in GCP, AWS, Azure, IBM Cloud, OpenShift or Rancher | Docker Compose on one VM for testing; Kubernetes with Helm or Terraform on AWS, Azure or GCP for production |
| Self-hosted license terms | Confirm the license and entitlement terms for self-hosted AX in your contract | MIT for core code; directories named ee are under a separate enterprise license |
| Data residency options | Confirm which regions are offered for managed AX; self-hosted AX runs in clusters you choose | Data stays wherever you deploy it, since self-hosted runs the same codebase as Langfuse Cloud |
| Storage components | Confirm the storage services required for your self-hosted AX deployment | PostgreSQL, ClickHouse, Redis or Valkey, and S3 or blob storage, plus Web and Worker containers |
Where your traces live and who can reach them
Arize AX, Phoenix and self-hosted Langfuse differ most in where trace data sits, how the platform is deployed and who controls sign-in. Each card below is a decision point for teams in regulated settings, and the checks at the end of each card are what to confirm before you commit.
Data location and residency
Trace data includes prompts, completions and retrieved documents, so its location is often the first question for a regulated team. Self-hosted Langfuse, Phoenix and Arize AX on Kubernetes keep traces in the infrastructure you choose, provided your storage and backups stay in that region. Confirm where PostgreSQL, ClickHouse and object storage run, and where any backups and log sinks are written, since a self-hosted stack can still copy data outside your chosen region by accident.
Hosting model and deployment path
Arize AX self-hosting runs on Kubernetes in GCP, AWS, Azure, IBM Cloud, OpenShift or Rancher environments and sits under an enterprise arrangement. Phoenix is a separate self-hosted tool with its own deployment. Langfuse documents Docker Compose on a single VM for testing, which has no high availability, and Kubernetes with Helm or Terraform for production. Ask which path your platform team can operate and staff for upgrades.
Identity and SSO
Single sign-on and role controls decide who can read production traces. Langfuse includes SSO in its self-hosted setup, but several controls such as project-level RBAC, audit logs and SCIM provisioning require an Enterprise license key. Check which identity features your identity provider needs against the edition you plan to run, and map Arize AX SSO and roles to the same requirements before comparing.
Licensing that governs internal access
Phoenix is licensed under the Elastic License 2.0, which permits internal self-hosting but bars offering it to third parties as a hosted or managed service. Langfuse core is MIT licensed outside its enterprise directories. If you plan to expose tracing to customers, a partner or a managed service, this license difference matters more than feature parity. Have counsel confirm the terms against your use case.
Compliance evidence and who issues it
Assessors ask for evidence that access, change and backup controls for the tracing stack work as described. DeployOpen can plan, configure and document these controls and assemble the evidence an assessor will request. Independent auditors and certification bodies issue the audit reports and attestations, not DeployOpen. Agree the evidence list with your assessor before the build starts so the stack is instrumented to produce it.
What drives the cost of self-hosting Langfuse
The main difference in cost is between a subscription with span-based allowances on the Arize AX side and a set of infrastructure and staff costs on the self-hosted side. Arize AX charges through its plans, and the allowances, retention windows and overage terms belong in the written contract, so confirm them there rather than working from list pricing. A self-hosted Langfuse deployment has no per-span fee from Langfuse itself, since the MIT-licensed core carries no usage limits. Its cost lies in the components it runs: Langfuse Web and Langfuse Worker, PostgreSQL, Redis or Valkey, ClickHouse, and S3-compatible blob storage. Each of these is a line item you pay for, whether through your cloud account, your data center, or your own hardware. The infrastructure line carries the largest recurring weight. Langfuse's scaling guide lists minimum resources of 2 CPU and 4 GiB for web, worker and PostgreSQL, 1 CPU and 1.5 GiB for Redis or Valkey, and 2 CPU and 8 GiB for ClickHouse, with at least 16 GiB of ClickHouse memory for larger deployments. ClickHouse usually drives the sizing, and its disk use grows with ingestion volume and retention length. High availability adds replicas for each stateful component. Object storage costs rise with the volume of raw events you keep. Ask your team to size these against your expected trace volume and the retention you need, and to confirm the figures against the current scaling guide before you commit.
Staff time is the component teams most often leave out of the comparison. Someone must run upgrades, back up PostgreSQL and ClickHouse, rotate secrets, monitor the worker queue, and plan capacity. Langfuse says updates within a major version apply database migrations automatically at startup, but major upgrades follow dedicated migration guides. The v3 to v4 guide requires ClickHouse 25.12 or later, PostgreSQL 15 or later and Redis 7.0 or later, and advises about 3x ClickHouse disk headroom when backfilling historic data. That headroom is a one-time cost during the migration, but it can require a temporary disk expansion, so plan it before you start. Staff effort is recurring, and it scales with how many components your platform team already runs. The optional Enterprise license key and the Self-Hosted Enterprise support plan are the remaining variables. Features such as data retention policies, audit logs, SCIM and project-level RBAC need the license key, and the support plan adds a named support engineer, solutions architect access and a support SLA. Both are priced by Langfuse on a custom basis. Ask for a written quote that separates the license, the support tier, the Arize AX subscription if you keep it during a transition, and any implementation work from DeployOpen, each with its own recurring or one-time status. Also ask for the span or ingestion assumptions behind each figure, so the comparison holds at your volume.
What a move from Arize AX to Langfuse involves
The sequence turns Arize AX tracing and evaluation into a self-hosted Langfuse deployment you control, with history, evaluators and prompts checked at each stage. The total effort depends mainly on how much trace history and how many evaluators you must carry over.
Inventory traces, datasets, evaluators and prompts
Your team lists every Arize AX project, the trace volume and retention you rely on, the datasets and experiments you reuse, each online and offline evaluator with its prompt template, and every prompt version tied to production. Decide which history must move and which can stay archived in Arize. The inventory is complete when each item has an owner and a keep or drop decision that your compliance and engineering leads have signed off.
Deploy and size a test Langfuse instance
Your platform team deploys Langfuse in a non-production environment, using Docker Compose on a single VM for testing or Helm on Kubernetes if you plan to run it in production. The stack includes Langfuse Web, Langfuse Worker, PostgreSQL, ClickHouse, Redis or Valkey, and S3-compatible storage. Size ClickHouse against the retention you need, since Arize plan limits do not apply to your storage. The step closes when a test project receives traces and the sizing matches a measured ingestion sample.
Repoint exporters through an OpenTelemetry Collector
Application engineers change the OpenTelemetry or OpenInference exporter endpoints so spans go to an OpenTelemetry Collector that your team operates. The Collector receives the spans, applies processing, and exports them to Langfuse with the required credentials, using authenticator extensions where your policy needs them. Your team confirms that span attributes such as model, token counts and session identifiers arrive intact in Langfuse. The step is done when parallel test traffic shows matching traces in both systems.
Export history from Arize and reshape it
Engineers pull the history you chose to keep using the Arize export tooling and load it into the object storage and ClickHouse path that Langfuse uses. Expect to map Arize span and dataset fields to the Langfuse data model, and confirm which historic records can be backfilled and which stay in Arize as a read-only archive. Plan disk headroom before backfilling, since the Langfuse upgrade guide advises about 3x ClickHouse disk headroom when backfilling historic data. The check is a row-count and sample comparison for each exported project.
Recreate evaluators and annotation workflows
Evaluation owners rebuild each retained evaluator as a Langfuse LLM-as-a-judge configuration or equivalent scoring method, then recreate annotation queues and the human review steps that Arize AX handled. Dataset and experiment comparisons also need to be rerun so scores can be compared with the Arize baseline. Confirm with the evaluation owners which steps are not yet covered by tooling and record them as open items. The step is complete when the rebuilt evaluators reproduce the baseline scores on a agreed sample of traces.
Run both systems in parallel
For a defined period agreed in advance, production traffic is sent to Arize AX and to self-hosted Langfuse at the same time. Your team compares trace completeness, latency impact, evaluator scores, alert behavior and access controls, and reviews the results with the application and compliance owners. Record any gap and fix it before cutover. The step closes with a signed comparison report that shows the two systems agree on the agreed metrics.
Cut over and decommission Arize
Once the parallel run passes, your team switches the production exporters to Langfuse only, removes the Arize keys from application and CI configuration, and sets a read-only or export-only state in Arize until retention obligations are met. Operations takes over Langfuse upgrades, which apply database migrations at startup within a major version, and major upgrades follow the dedicated migration guides. The step is complete when no production service sends spans to Arize and the backup and retention runbook is in place.
Questions buyers ask before choosing Langfuse or Arize
How much staff time does self-hosting Langfuse take?
The staff time depends mostly on the size of your trace volume, how many environments you run, and whether your platform team already operates PostgreSQL, ClickHouse, Redis or Valkey, and S3-compatible storage. Langfuse's documentation describes two application containers, Langfuse Web and Langfuse Worker, plus those four supporting stores. A single-VM Docker Compose setup is documented for testing only and has no high availability, so production work means Kubernetes with Helm or Terraform. Routine updates within a major version run database migrations at startup, while major upgrades follow dedicated migration guides. Ask your implementation partner to break the effort into initial build, hardening, backup, upgrades and ongoing operations, and ask which of those your own team keeps.
Can our team run self-hosted Langfuse without outside help?
Yes, if your team already runs Kubernetes, managed or self-managed PostgreSQL, ClickHouse and object storage, and has someone who can own upgrades and on-call response. Teams without those skills usually need outside help for the first deployment, sizing and the first major upgrade. Langfuse's scaling guide lists minimum resources for web, worker, PostgreSQL, Redis or Valkey and ClickHouse, and recommends scaling workers on CPU load and splitting ingestion from the user interface under heavy ingestion. Confirm internally who owns each component, then decide whether you want fixed-scope implementation, a retainer for upgrades and support, or a mix of both.
What does a migration from Arize to Langfuse involve?
A migration has four workstreams: repointing your instrumentation, rebuilding datasets and evaluators, moving history you need to keep, and sizing the storage that will hold your retention window. Langfuse accepts OpenTelemetry traces, so teams already using OpenTelemetry or OpenInference exporters usually change endpoints and credentials rather than instrumentation. Evaluators and human review queues need to be recreated in the new tool. Historical data exported from Arize needs reshaping before it loads. The duration depends on how many applications, datasets and evaluators you have, so request a timeline in the written scope rather than relying on a general estimate.
Does self-hosted Langfuse support SSO and SCIM?
Langfuse's authentication documentation covers single sign-on for self-hosted deployments, but some identity features sit behind an Enterprise license key. The key-gated list includes project-level RBAC roles, audit logs, data retention policies, server-side data masking, and the organization management API with SCIM. Confirm with Langfuse which SSO protocol and identity provider settings your environment needs, and check the license key documentation before you commit to a design. Your identity team should verify group mapping and offboarding behavior in a test environment before go-live.
Does Langfuse's MIT license differ from Arize Phoenix's license?
Yes. Langfuse's repository is MIT licensed outside its ee directories, and Langfuse states that all core features and APIs are available in the MIT version without limits. Arize Phoenix is licensed under the Elastic License 2.0, which is not OSI-approved and forbids offering the software to third parties as a hosted or managed service. Internal self-hosting is a different question from offering a service to customers, so have your legal team review the license text for your use case. Opik, under Apache-2.0, is another option if you want an OSI-licensed self-hosted tool with the full platform.
Are Phoenix or Opik better fits than Langfuse?
It depends on which feature set matters most. Phoenix keeps you on the same OpenTelemetry and OpenInference instrumentation as Arize AX, which lowers instrumentation change, but its Elastic License 2.0 terms apply. Opik is Apache-2.0 and documents self-hosting of its server, web application, tracing, evaluations and prompt management without a commercial license. Langfuse is MIT outside its ee directories and has a mature self-hosted deployment guide with a larger set of documented storage components. Compare the evaluation metrics, prompt management and retention controls you rely on in Arize today against each tool's documentation, and run a short pilot on your own traces before deciding.
What should we ask for in a written scope and quote?
Ask for a written scope that names each deliverable: the target architecture, Kubernetes and storage components, hardening, backup and restore testing, upgrade procedure, SSO configuration, instrumentation changes and evaluator migration. Request the assumptions behind any effort figure, including trace volume, number of environments, retention window and which enterprise features you need. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted platforms in your own infrastructure, and most engagements are fixed-scope with deliverables and timelines agreed in writing before work starts. DeployOpen does not publish a price list, so the written scope is the source for any project-specific cost or schedule.
Why the license of each self-hosted option matters
The license decides what your organization may do with the software, not only what it costs. Langfuse core is MIT licensed everywhere outside its ee directories, and the Langfuse documentation states that all core features and APIs are available in that open source version without limits. Features that need an enterprise license key are a separate matter: project-level RBAC roles, protected prompt labels, data retention policies, audit logs, server-side data masking, UI customization, and the SCIM and instance management APIs. If your requirements list any of these, confirm with Langfuse which key and terms apply before you design around the open core alone.
Arize Phoenix is licensed under the Elastic License 2.0, which is source-available rather than OSI-approved open source. Under its terms, your own staff can run Phoenix internally, but you may not offer it to third parties as a hosted or managed service. This matters most if you plan to build an internal tracing service for customers, a partner platform, or a product that exposes Phoenix to outside users. It also matters if your procurement policy only accepts OSI-approved licenses, because Phoenix will not meet that rule even though it is free to run. Opik, which is Apache-2.0, avoids both constraints.
Have counsel confirm the license terms against your specific use case before you commit, including how the Langfuse ee boundary applies to the features you need, whether any internal use qualifies as a managed service under the Elastic License 2.0, and what your procurement rules require. Ask each vendor to state its license position in writing. Record the answer alongside the architecture decision, because a license change later can force a migration even when the technical design stays the same.
How DeployOpen helps you evaluate, implement or migrate
DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Arize vs Langfuse, we start from your trace volumes, retention needs, identity and residency requirements, and then build the Langfuse deployment you choose or prepare a Phoenix or Opik comparison.
How we scope
- Written scope covers which Arize AX features you use and which Langfuse capabilities replace them.
- We record span volumes, retention periods and data residency requirements before any architecture is proposed.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- We deploy Langfuse Web, Langfuse Worker, PostgreSQL, ClickHouse, Redis or Valkey and S3-compatible storage in your environment.
- We repoint OpenTelemetry and OpenInference exporters and test traces end to end against the new endpoints.
- We size ClickHouse and worker capacity for your retention target and test backup and restore of the stores.
How we hand over
- You receive architecture documentation, configuration records, runbooks and a written list of licensing decisions for each component.
- We document which features need a Langfuse Enterprise license key, so you decide on them with full information.
- Handover includes upgrade procedures, including the separate migration guide for major versions such as v3 to v4.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover monitoring of ingestion load, scaling changes and planned major-version upgrades.
- Confirm with us and your own security team which control evidence you need for any compliance assessment, since independent auditors issue the reports.
