Arize vs Opik: when each fits and what the decision turns on
If your Arize AX renewal is due or you need an OSI-licensed tracer you can run yourself, Arize AX fits teams that want a managed platform with vendor support and existing AX workflows, while Opik fits teams that need Apache-2.0 self-hosting, control over where trace data is stored and no span allowance. Neither answer is universal, so the choice depends on what your team can operate and what your compliance and data owners require. Arize AX suits organizations that prefer the vendor to run the platform, that already have dashboards, datasets and evaluators built in AX, and that want a single support contract. Opik suits teams that will run the stack themselves: its server, web application, tracing, evaluations and prompt management can be self-hosted without a commercial license, and it uses ClickHouse, MySQL and Redis, so storage is sized by your own infrastructure rather than by a plan's span limits. Confirm the current AX self-hosting terms, including the Enterprise plan requirement, with Arize before you treat them as an option.
The decision turns on four questions. First, operating capacity: who will upgrade ClickHouse, back up MySQL, patch Redis and rotate Opik releases, and do you have an on-call path for them? Second, SSO requirements: check whether your identity provider integration and role model are needed on day one, and ask both vendors which features sit behind an enterprise tier. Third, evaluation needs: list the LLM-as-a-judge metrics, online rules and guardrails you use today and test each in Opik during a pilot. Fourth, whether Phoenix's Elastic License 2.0 terms were the trigger. If your concern is that ELv2 bars offering Phoenix to third parties as a managed service, Opik's Apache-2.0 license removes that question, but you should still document how your internal use fits your own obligations. Before committing, run a pilot on a copy of production traces, measure storage growth against your retention needs and write down the support route you will use if the self-hosted stack fails. That written list will let you compare a quote for implementation and ongoing operations against Arize's contract on equal terms.
Which option fits which buying scenario
This table maps common buying situations to the better fit between Arize AX and self-hosted Opik. Read each row as a conditional: the right answer depends on whether your team can operate the Opik data stack and whether a managed service or an OSI license is the deciding factor.
| Scenario | Better fit | Why |
|---|---|---|
| Renewal under span pressure | Opik, self-hosted | Opik has no per-span allowance in its license; your cost moves to ClickHouse, MySQL and Redis capacity you size and run. Confirm your expected trace volume before comparing. |
| Strict OSI open-source license requirement | Opik, self-hosted | Opik is Apache-2.0 and its README says the full platform can be self-hosted without a commercial license. Arize Phoenix is under the Elastic License 2.0, which is not OSI-approved, so it does not meet this requirement. |
| Need for managed operations and vendor support | Arize AX | Arize runs the platform for you. Opik's hosted option on Comet.com is the managed alternative if you want Opik without self-hosting; confirm its terms and regions with Comet. |
| Air-gapped deployment | Opik, self-hosted | Opik runs on Kubernetes with Helm charts and can be deployed inside your network, provided you mirror images and dependencies. Arize AX self-hosting is an Enterprise option, so confirm its air-gapped support with Arize. |
| OpenTelemetry-first stack | Either, depending on operations capacity | Opik supports OpenTelemetry and native framework integrations. If you also run the OpenTelemetry Collector as a gateway, Opik fits when your team can operate its storage; Arize AX fits when you prefer Arize to own the backend. |
| Team can operate ClickHouse, MySQL and Redis | Opik, self-hosted | Opik's infrastructure uses these three components, so this option fits when you already have database and cache operations skills and on-call coverage. |
| Team has no database operations capacity | Arize AX or Opik hosted on Comet.com | Running ClickHouse, MySQL and Redis yourself adds upgrades, backups and capacity work. A managed service shifts that work to the vendor under its terms. |
| Need for SSO and enterprise access controls | Confirm with each vendor | Check which SSO and role features each plan and self-hosted edition includes in writing before deciding, since the feature split changes by edition. |
Why Apache-2.0 and the Elastic License 2.0 are different decisions
Phoenix and Opik are not interchangeable on licensing, even though both are self-hosted tracing and evaluation tools. Arize Phoenix is licensed under the Elastic License 2.0, which is not an OSI-approved open-source license. The license permits internal self-hosting but forbids offering Phoenix to third parties as a hosted or managed service, so a company that runs it for its own engineers is in a different position from a company that sells LLM observability to customers. Opik, maintained by Comet, is Apache-2.0 licensed, and its README states that the full platform, including the server backend, web application, tracing, evaluations and prompt management, can be self-hosted without a commercial license. Ask your legal team which of these terms matter for your use, such as internal use, contractors, or any customer-facing product built on trace data, and read the Phoenix LICENSE file directly rather than relying on a summary.
Arize AX is a different kind of product. It is a commercial managed enterprise platform, and Arize also documents a self-hosted option that runs on Kubernetes across several cloud and on-premises environments. That option is a commercial arrangement, so the terms that govern it come from your Arize agreement, not from an open-source license. Do not assume that a self-hosted AX deployment carries the same freedoms as Opik or Phoenix. Confirm in writing which AX edition you would run, what license or subscription it requires, and what the agreement says about upgrades, support and data handling. The same discipline applies to Comet: Opik's self-hosted edition is Apache-2.0, but Comet's hosted Opik service on Comet.com is a separate commercial offering with its own terms.
Before you choose, write down the use case in license language: who will run the software, who will use its output, and whether any end customer or partner will interact with it. If the answer is internal engineering only, Phoenix may be workable and the Elastic License 2.0 terms may be acceptable. If you expect to offer LLM tracing as a service to others, or want an OSI-approved license in your procurement policy, Opik's Apache-2.0 terms are the simpler position to document. Record the decision, the license version you reviewed and the date, so the choice can be revisited when a vendor changes its terms.
Where traces, prompts and keys live under each option
Each option places trace data, prompts and API keys in a different location and under a different operator's control. The cards below cover where that data sits, who runs the software, and which identity and evidence questions each choice raises for an Arize vs Opik decision.
Arize AX managed hosting
Arize AX is a managed enterprise platform, so Arize operates the environment, storage and upgrades, and your spans, prompts and evaluation results sit in Arize-run infrastructure. Your team's work shifts to configuring projects, access and data retention within the plan you buy. Ask Arize which region hosts your tenant, how long spans are retained on your plan, and how API keys are scoped and rotated before you commit.
Arize AX self-hosting on Kubernetes
Self-hosted AX runs on Kubernetes in GCP, AWS, Azure, IBM Cloud, OpenShift or Rancher environments, which keeps trace data inside your own accounts. You take on the cluster, storage, backups and upgrades, and the self-hosted option is a separate commitment from the managed product. Confirm the edition, license terms and support scope in writing, because the self-hosted route is not the same as running the open-source Phoenix tool.
Opik self-hosting with Docker Compose or Helm
Opik is Apache-2.0 licensed, and its README states the full platform, including the server, web application, tracing and evaluations, can be self-hosted without a commercial license. Local testing uses the opik.sh script with Docker Compose, while production uses Helm charts on Kubernetes. Your team owns the ClickHouse, MySQL and Redis stores that hold traces, prompts and keys, so backup, encryption and access reviews move to your own runbooks.
Comet-hosted Opik
Opik is also offered as a hosted service on Comet.com, so the same product can run with Comet operating the platform. Your traces and prompts then live in Comet's environment rather than in your cluster, which changes the residency and vendor review. Confirm where the hosted tenant runs, how data is isolated, and what Comet's contract says about deletion and subprocessors before sending production traces.
Identity and SSO options
Single sign-on, role-based access and API key management differ between managed and self-hosted editions, and the differences decide who can see prompts and production traces. Map each option's SSO protocols, group sync and key rotation against your identity provider, and confirm in writing which SSO options each edition supports. Keep service keys for OpenTelemetry exporters separate from human logins so revoking one does not break the other.
Residency and compliance evidence
Where traces and prompts are stored determines which residency and control evidence you need, and self-hosting moves that evidence onto your own controls. DeployOpen prepares systems, configurations and evidence for compliance assessments, but independent auditors and certification bodies issue any report or attestation. Ask each vendor for its own audit reports and data processing terms, and treat your self-hosted evidence as an input to that review.
How OpenTelemetry support changes the exit path
OpenTelemetry is the piece of the stack that makes an exit from Arize AX less of a rewrite. It is a vendor-agnostic framework for generating, exporting and collecting telemetry such as traces, metrics and logs. It does not store or visualize that data. Storage and the query interface are a separate decision, so moving off Arize AX means choosing a backend for the spans you already emit. Opik is that backend for this comparison. Phoenix and Arize AX use OpenTelemetry and OpenInference as well, so the instrumentation you already run is the first thing to audit before any backend change.
The OpenTelemetry Collector is the component to plan around. It is licensed under Apache-2.0, receives, processes and exports telemetry, and can run as an agent beside services or as a gateway that accepts data from many sources. Placing a Collector between your applications and Opik lets you change exporters later without touching application code. Its releases ship the contrib distribution with signed artifacts, SHA256 checksums and SBOM files. Verify those signatures and checksums in your own pipeline before you deploy a new Collector version, and record the SBOM for your supply chain review.
Opik accepts OpenTelemetry data alongside its native SDKs and the @track decorator, so you can choose per service whether to keep OpenTelemetry or move to Opik's SDK. Before you commit to either path, check each signal and language you rely on against the OpenTelemetry status page. Trace SDKs are stable in most languages, but log SDK maturity varies and some Collector components have mixed stability levels. Confirm the Opik mapping for your framework and attributes in a test environment, because OpenTelemetry support does not guarantee that every Arize-specific attribute or evaluation field carries over unchanged.
Running Opik yourself versus buying Arize AX
A platform team that already runs ClickHouse in production can treat Opik as one more stateful service. The team operates the Opik application and its storage, sizes ClickHouse for its own trace volume, and keeps trace data inside its network. In return, it has no span allowance to manage and does not wait on a vendor for storage changes.
- What the team operates: the Opik services plus ClickHouse, MySQL and Redis, deployed with the Docker Compose path for local use or the Helm charts for production.
- What the vendor provides: Apache-2.0 code for the full platform, including the server backend, web application, evaluations and prompt management, which can be self-hosted without a commercial license.
- Scale to validate: the Opik README states 40M+ traces per day. Treat that as the vendor's stated figure and confirm it with your own load tests and retention plan.
- When the trade-off makes sense: on-call coverage for ClickHouse already exists, and avoiding plan-based span limits matters more to you than managed convenience.
Confirm your ClickHouse backup restore tests and on-call rota before committing to this model.
A team without database operations capacity should price the storage layer honestly before choosing self-hosting. Opik still needs ClickHouse, MySQL and Redis even when the application team runs the Opik services, so the real question is who patches, backs up and restores those stores. A managed Arize AX plan or Comet's hosted Opik moves that work to the vendor.
- Hidden components: three data stores that each need patching, monitoring and capacity planning alongside the application.
- Recurring costs: engineer time for upgrades and incidents recurs with every release cycle, while the initial deployment is mostly one-time effort.
- Vendor options: Opik is also offered as a hosted service on Comet.com, and Arize AX is a managed platform with plan-based span allowances and retention tiers. Ask each vendor for current limits in writing.
- Outside help: fixed-scope setup and retainers for upgrades and support can cover the gap, with scope, deliverables and timelines agreed in writing before work starts.
- Conditions: the self-hosted route works only when one named owner accepts database on-call duties.
Ask who owns ClickHouse upgrades and restores, in writing, before the pilot begins.
A regulated team often needs a named vendor, written support terms and contract documents to show assessors. Arize AX offers a self-hosted deployment on Kubernetes in several cloud and platform environments, and Comet hosts Opik, but each choice changes who holds the operational evidence. Self-hosted Opik keeps trace data in infrastructure you choose, while your own controls cover operations.
- What the team operates: with managed AX or hosted Opik, the vendor runs the platform. With self-hosted Opik, your team keeps the evidence for every control it relies on.
- What the vendor provides: support, SSO options and documentation that depend on plan and deployment, which you must confirm in writing.
- Residency and access: hosted options place data with the vendor, while self-hosting keeps it in your chosen environment.
- Assessor evidence: request current audit reports and the subprocessor list from each vendor. DeployOpen prepares systems, controls and evidence for assessments, but independent auditors issue the reports.
- When it makes sense: procurement rules require a contracted vendor, or the team lacks the staff to run ClickHouse under audit scrutiny.
Ask each vendor for SSO terms, support commitments and audit reports in writing before comparing costs.
What each option costs to own, by component
Arize AX and self-hosted Opik charge for different things. Arize's cost sits in a subscription with usage tiers, while Opik's cost sits in the infrastructure and people you run yourself. Each card below names one component, whether it is one-time or recurring, and what moves it up or down.
Arize AX subscription and tiers
Arize AX is a paid managed platform, so its main recurring cost is the subscription, shaped by span allowances, retention periods and plan level. Ask Arize for a written quote that states the included span volume, overage rates, retention window for traces and evaluations, and the terms for any multi-year commitment. Compare that quote against your projected trace volume for the next 12 months, not your current pilot traffic.
Enterprise terms for self-hosted AX
Running Arize AX in your own Kubernetes environment is an enterprise arrangement, not a self-service download, so it adds contract terms on top of the subscription. Ask whether the license covers the cloud environments you use (GCP, AWS, Azure, IBM Cloud, OpenShift or Rancher), who handles upgrades, and what support response commitments are included. Get these terms in writing before comparing totals, because they often change the figure more than the list tier does.
Opik software license
Opik is Apache-2.0 licensed, and its README states the full platform can be self-hosted without a commercial license. The software line item is therefore zero, but you still own the cost of changing the deployment, applying upgrades and keeping the platform in your change process. Confirm that your legal team accepts the Apache-2.0 terms and that you do not want the hosted Comet.com service for any part of the workload.
ClickHouse, MySQL and Redis infrastructure
Opik's backing services are ClickHouse for trace storage, MySQL and Redis, and each one is recurring compute and storage you provision, monitor and back up. ClickHouse is usually the largest driver, since its footprint grows with span volume and retention. Ask your platform team to size ClickHouse against your own daily trace volume and retention target, and to price replicas and backups in the same estimate.
Object storage and backups
Object storage holds backups and any exported data, and it recurs monthly in proportion to the volume you keep. Choose the retention period first, because it decides how much storage you pay for over time. Confirm where backups sit, how often they are restored in test, and whether your storage provider charges for egress when you move data out.
Kubernetes capacity and operations
Opik's production path runs on Kubernetes with Helm charts, so cluster nodes, load balancers and monitoring are recurring costs in your cloud or data center account. Staffing is the less visible line: someone must own the cluster, the Helm upgrades and the on-call rotation for trace ingestion. Estimate the platform engineering hours your team can spare each month, and treat any shortfall as a cost to outsource or to avoid.
SSO, support and upgrade effort
SSO, vendor support and upgrade work are where the two options differ most in kind. Arize AX includes support and managed upgrades under its contract, while self-hosted Opik leaves SSO integration, upgrade testing and incident response with your team or a partner you engage. Ask Arize which SSO protocols and support levels the contract includes, and ask Comet what the community and commercial support paths cover before you decide.
What moving from Arize AX to self-hosted Opik involves
The sequence turns Arize AX tracing, datasets and evaluators into a self-hosted Opik deployment that your team operates, with a parallel run that proves the new setup before AX is retired.
Inventory spans, datasets, evaluators and prompts
Your engineering lead and an evaluation owner list what runs in Arize AX today: which applications send traces, which projects and spans carry business-critical data, which datasets and experiments are kept, which evaluators score production traffic, and which prompts are versioned and where. Record retention needs and who reads each output. The step is done when the list is agreed and every item has an owner and a target in Opik, so nothing is lost by omission.
Export history with the Arize client
A platform engineer uses the Arize Python export client to pull traces, datasets and experiment results into local files, typically as pandas DataFrames, and stores them in a controlled location with access limited to the migration team. Spans and evaluation scores are reshaped into the fields Opik expects before any import. The step is done when row counts and sample records match what AX shows for the same projects and date ranges, and the export is recorded in your data inventory.
Deploy Opik with Docker Compose or Helm
An infrastructure team deploys Opik in your own environment. Docker Compose, started through the opik.sh script, suits a local evaluation or pilot. Helm charts on Kubernetes are the production path. Opik's infrastructure uses ClickHouse, MySQL and Redis, so the team sizes storage for the retention you need, sets up backups, and places the instance under your identity, network and logging controls. The step is done when the UI loads, a test trace arrives and the backup and restore procedure has been run once.
Re-instrument applications with OpenTelemetry or Opik SDKs
Application developers point each service at Opik. Teams already using OpenTelemetry can keep that instrumentation and change the exporter target, while others can use Opik's native integrations for LangChain, LangGraph, LlamaIndex, CrewAI and other frameworks, or the @track decorator for custom code. Confirm with your Arize instrumentation whether spans map cleanly to Opik's trace model, especially for multi-step agents. The step is done when a staging workload produces traces in Opik with inputs, outputs, token usage and nested steps intact.
Rebuild evaluators and LLM-as-a-judge metrics
An evaluation owner recreates each production evaluator in Opik, including the LLM-as-a-judge metrics for hallucination, moderation and RAG, and sets up online evaluation rules where AX scored live traffic. Judge models, prompts and thresholds are written down, because scores from different metrics or judge models are not directly comparable. Human review queues that existed in AX need a replacement workflow. The step is done when reference datasets produce scores in Opik that the owner has checked against known good and bad examples.
Run Opik and Arize AX in parallel
Both systems receive the same production traffic for an agreed period, and the team compares trace completeness, latency overhead, evaluator scores and alert behavior side by side. Discrepancies are traced to instrumentation, sampling or metric configuration and fixed before cutover. The step is done when the owners sign off that every critical dashboard and alert has an Opik equivalent and that the differences are understood and accepted in writing.
Cut over and retire Arize AX
The team switches all production exporters to Opik, freezes Arize configuration, and confirms that access and retention policies apply to the new system. Final exports are archived according to your records policy, and contract or subscription terms with Arize are closed out with the vendor. The step is done when no production service sends new data to AX, the archive is verified, and the operations runbook lists who owns Opik upgrades, backups and support going forward.
Questions buyers ask before choosing Opik or Arize AX
How much effort does a self-hosted Opik deployment take?
Effort depends mostly on how many services you run and how much trace volume you expect. Opik's README documents Docker Compose through its opik.sh script for local use and Helm charts on Kubernetes for production. Its infrastructure uses ClickHouse, MySQL and Redis, so your team owns three stateful components, backups, upgrades and capacity planning beyond the application itself. The README states the platform handles 40M+ traces per day, but your sizing will depend on span size, retention and query patterns. Ask your team to pilot with your real trace shape before settling on a sizing plan.
Can our team deploy Opik without outside help?
A team with Kubernetes, database and observability experience can usually deploy Opik from the published Helm charts without a vendor. The harder work is operational: monitoring ClickHouse, keeping MySQL and Redis healthy, rotating credentials, testing restores and planning upgrades across releases. Teams without those skills often bring in a partner for the initial build, hardening and runbooks, then run the platform themselves. DeployOpen implements, hardens, backs up, upgrades and documents self-hosted platforms inside your own infrastructure under a written, fixed scope, and offers ongoing support as a retainer.
What must our team provide for a self-hosted Opik setup?
Your team provides the infrastructure, a named owner for each stateful component and the model access used by LLM-as-a-judge metrics. Typical items to plan for are:
- A Kubernetes cluster or host capacity for Docker Compose testing, with storage for ClickHouse, MySQL and Redis
- Backup and restore for ClickHouse and MySQL, plus a tested recovery procedure
- Network access for your instrumented applications and the users of the web interface
- Evaluator model access, which may be an external provider or a model you host, and a decision on where judge prompts and trace content may be sent
Confirm each owner before the pilot starts, because evaluator model choices affect data residency.
How long does a migration from Arize AX to Opik take?
No general migration duration is published here, and the pace is set by your own inventory. The main drivers are the number of applications instrumented, whether you re-instrument with OpenTelemetry or the Opik SDKs, how much historical data you need to carry over, how many evaluators and datasets must be rebuilt, and how many teams must validate results. Start by listing instrumented services, evaluators and datasets, then decide which history is worth exporting. Ask any implementation partner for a timeline in the written scope rather than relying on an estimate in a sales conversation.
Does Opik support SSO, and what should we confirm?
The Opik README describes the platform as self-hostable without a commercial license, but this page has no supplied fact confirming a specific SSO or SAML mechanism. Before committing, confirm with Comet and in a proof of concept whether the self-hosted build provides SSO, which identity protocols it supports, how user roles map to your groups, and whether any capability sits behind a paid tier. Also confirm how audit logging and access reviews would work for your compliance program, since those requirements often decide between a managed and a self-hosted option.
Can Opik replace our Arize evaluations, and what needs rebuilding?
Opik covers several evaluation needs that Arize teams use: it provides LLM-as-a-judge metrics for hallucination, moderation and RAG, online evaluation rules, and experiments tied to datasets. Evaluation templates and scores do not transfer automatically, so each evaluator, judge prompt and dataset must be recreated and checked against known results. Human review steps and annotation workflows may need tooling that Opik does not replace one for one, so confirm those in your pilot. Keep a baseline of Arize scores so you can compare outputs before cutting over.
What should a quote for self-hosted Opik include?
A useful quote separates one-time work from recurring work and names every component. Ask for the following in writing:
- Scope of deployment for Opik, ClickHouse, MySQL and Redis, with the environment and Kubernetes or host layout
- Instrumentation and migration work, including which evaluators, datasets and prompts are rebuilt
- SSO, backup and restore testing, and hardening against your security baseline
- Pilot exit criteria, acceptance tests and a named handover to your operators
- Ongoing support, upgrade and monitoring terms, if you want a retainer
Also ask for infrastructure and model costs to be listed separately, since those are paid to your cloud provider or model vendor, not to the implementer.
How DeployOpen helps teams evaluate, implement or migrate
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up, upgrades and documents self-hosted platforms inside the client's own cloud accounts, data centers or air-gapped networks. For a move from Arize AX to Opik, that means the Opik server, its ClickHouse, MySQL and Redis dependencies, the OpenTelemetry Collector path, and the SSO and access configuration are set up and operated in your environment, not in a DeployOpen-hosted tenant. DeployOpen also runs security testing of AI systems, so the tracing and evaluation stack can be tested alongside the applications and agents that feed it. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. DeployOpen does not publish a price list, so the quote follows from that written scope.
A useful first step is a short evaluation scope that covers the decisions this comparison raises. Confirm which Arize AX features your teams rely on, which span volumes and retention periods you need, which evaluators and human review queues must be rebuilt, and whether your identity provider and SSO requirements can be met by the self-hosted option you choose. Ask for the deliverables to be named in the written scope, such as a sizing note for ClickHouse storage, an exporter and instrumentation plan, a Kubernetes or Docker Compose deployment, a backup and restore test, and an upgrade procedure. Quotes depend on those items, so the scope is the main lever on cost.
DeployOpen prepares systems, controls and evidence for compliance assessments, including configuration records, access reviews and backup evidence. It does not issue audit reports, attestations or certifications; independent auditors and certification bodies do that work. If your organization must show controls for an assessment, confirm with your auditor which evidence they expect before implementation begins. Ongoing support, upgrades and continuous testing are available as a retainer, which suits teams that will run Opik through regular release cycles after the migration is complete.
