When LangSmith or Phoenix is the right choice
If you are facing a LangSmith renewal, an Enterprise self-hosting quote, or a data residency or licensing concern, the choice comes down to four questions: whether you need managed cloud or self-hosting, how heavily you run LangChain and LangGraph, whether you require an OSI-approved license, and how much evaluation depth your team needs. LangSmith fits teams that are already built on LangChain and LangGraph, want a managed cloud region, and need deep evaluation workflows. Phoenix fits teams that want to self-host tracing and evaluation with no feature limits or license fees, instrumented on OpenTelemetry and OpenInference rather than a framework-specific SDK. Phoenix's documented self-hosting covers terminal, Docker, Kubernetes, Helm and several cloud templates, and it supports SQLite by default or PostgreSQL through PHOENIX_SQL_DATABASE_URL.
Be clear about the license before standardizing on Phoenix. Phoenix is licensed under the Elastic License 2.0, which is source-available and not an OSI-approved open-source license. ELv2 forbids providing the software to third parties as a hosted or managed service and forbids circumventing license key functionality. For an internal platform team running Phoenix for its own engineers, this is usually not a constraint. It becomes one if you plan to resell, host or offer tracing as a service to customers or partners. Confirm your intended use against the Phoenix LICENSE file and, where the answer is unclear, obtain a written view from your legal team.
If you need an OSI-approved license for every component, or a platform where the full feature set is open, Phoenix is the wrong fit and you should look at other open-source options in this hub. If your evaluation needs are heavy, such as annotation queues, online evaluators and CI-gated experiments, compare Phoenix's evaluation features with your current LangSmith workflows before committing, because the two platforms differ in how far they go. Ask your team to list the evaluations they run each week and check each one against Phoenix's documentation during a trial on a non-production dataset.
Which option fits which scenario
This table maps common buyer scenarios to the platform that usually fits best, along with the condition that drives the choice. Read each row against your own constraints, such as plan, licensing, network access and who will operate the stack. Several rows depend on facts you should confirm with each vendor before deciding.
| Scenario | Better fit | Condition that drives the choice |
|---|---|---|
| LangChain-centric stack on managed cloud | LangSmith Cloud | Your team already instruments with LangChain and LangGraph callbacks and accepts a managed region such as GCP EU or AWS US. |
| Self-hosting required without an enterprise contract | Arize Phoenix | Phoenix is free to self-host with no feature limits, but ELv2 restricts offering it as a hosted service to third parties. |
| Self-hosting required with an enterprise contract | Self-hosted LangSmith | You already hold or are willing to buy the Enterprise add-on and license key, and deploy to Kubernetes with Helm or Terraform. |
| OpenTelemetry-first instrumentation | Arize Phoenix | Your services emit OpenTelemetry spans and you want OpenInference semantics for LLM calls across the same pipeline. |
| Air-gapped or disconnected networks | Arize Phoenix | Phoenix documents air-gapped deployment with no license key check; confirm that your mirrored images and model access meet your own controls. |
| EU data residency | Depends on the deployment model | LangSmith Cloud offers a GCP EU region with billing in the US, while Phoenix keeps traces in the infrastructure you choose. Confirm where each component runs. |
| Hosting Phoenix as a service for other teams | Confirm with counsel before choosing | ELv2 forbids providing the software to third parties as a hosted or managed service, so internal use across your own business units should be reviewed against the license terms. |
| Full platform self-hosted with no license key and prompt management included | Consider Opik or Langfuse | Phoenix's free self-hosting covers tracing and prompts, but if you need an OSI-approved license across the whole stack, compare Apache-2.0 Opik or open-core Langfuse. |
What Elastic License 2.0 allows and what it does not
Arize Phoenix is source-available under the Elastic License 2.0 (ELv2), not under an OSI-approved open source license. That distinction matters for a compliance file and for procurement, because many internal policies only accept OSI-approved licenses without an exception. Phoenix's license file, which is the document to read first, lets you use, copy, modify and self-host the software for your own purposes. Phoenix's self-hosting docs also say it is free to self-host with no feature limitations, no license fees and no usage limits, and that traces, prompts and data stay in your infrastructure, including air-gapped deployments.
ELv2 draws its main line at hosting. It forbids providing the software to third parties as a hosted or managed service, so you cannot run Phoenix for other companies or sell access to it as a service. It also forbids circumventing license key functionality. Phoenix's current self-hosted feature set does not depend on a license key, so the restriction matters mostly if you ever build a product on top of Phoenix or modify its key-related code. Ask counsel whether an internal platform team serving several business units counts as providing a managed service, and whether any subsidiary or contractor operating Phoenix for a third party changes the answer.
Compare this with LangSmith self-hosting. It is an add-on to LangChain's Enterprise plan, it needs a license key, and it deploys to your Kubernetes cluster through Helm charts, with Terraform also documented in the LangSmith self-hosting docs. Your contract, not the software license alone, governs what you may run. Before you standardize on either product, have counsel review the current license text, your contract and your use case, including whether external contractors may administer the deployment. This section is an overview, not legal advice.
Where traces and prompts live under each option
Each option makes a different decision about where trace data, prompts and evaluation records sit and who can reach them. The cards below compare LangSmith's regional cloud and self-hosted add-on with Phoenix's self-hosting paths and access controls, so you can confirm the placement your residency and audit requirements need.
LangSmith Cloud regions
LangSmith Cloud runs in GCP US (Iowa), GCP EU (Netherlands), GCP APAC (Sydney) and AWS US (Ohio). Trace data stays in the region where the account signed up, but billing information stays in the US. If your residency rules cover billing or account metadata, that split matters even when traces stay in the EU. Confirm with LangChain which region your account is in and what metadata leaves it.
Self-hosted LangSmith on Kubernetes
Self-hosted LangSmith is an add-on to LangChain's Enterprise plan. It requires a license key and deploys to your Kubernetes cluster with Helm charts, with Terraform also documented. Your team then owns the cluster, storage, upgrades and backups. Ask LangChain what the license check sends from your network before you plan the deployment, because that determines the egress rules you must allow.
Phoenix self-hosting paths
Phoenix can be run from a terminal, Docker, Kubernetes or Helm, and through AWS CloudFormation, Railway, Render, Google Cloud Run and Azure ARM templates. Storage defaults to a file-based SQLite database, and PostgreSQL is supported through PHOENIX_SQL_DATABASE_URL or separate connection variables. SQLite suits a single evaluation host, while production teams should plan for PostgreSQL and its backups.
Data stays in your infrastructure
Phoenix states that traces, prompts and data stay in your infrastructure, including in air-gapped deployments, and that self-hosting carries no license fees, feature limits or usage limits. Because the data never leaves your environment, the controls around it are yours to design. Document where the database volume, backups and any exports live, and confirm that your network policy matches the placement you describe to auditors.
Identity options and roles
Self-hosted Phoenix supports OAuth2, LDAP and local accounts, with role-based permissions applied to users. Choose the identity source before go-live so that offboarding and role changes flow from your directory rather than from manually maintained local accounts. Test how role assignments map to projects and prompts, since access control is where most review findings in tracing platforms appear.
SQLite or PostgreSQL: choosing Phoenix storage
Phoenix starts with a file-based SQLite database by default, so a single process on one machine can store traces, datasets and prompts without a separate database server. This suits a proof of concept, a developer workstation or a small internal pilot where one team checks whether the tracing and evaluation workflow fits. The trade-off is that the database is a file on the host, so its durability, backup and access depend entirely on that host.
- Setup: No database service is needed, so the first deployment involves only the Phoenix process and its storage path.
- Backups: Copying the database file while Phoenix is stopped, or using a consistent snapshot of the volume, is the usual approach. Confirm the procedure with your own storage team.
- Concurrency: A single writer on one node is the expected pattern. Several Phoenix replicas should not share one SQLite file.
- Upgrades: Back up the file before each Phoenix version change and test the upgrade on a copy first.
- Scale: Confirm with your own trace volume whether a single file remains manageable as traces accumulate.
Before relying on SQLite for anything beyond a pilot, confirm the volume's backup and restore path with your operations team.
For production, Phoenix supports PostgreSQL through the PHOENIX_SQL_DATABASE_URL variable or through separate connection variables, according to the Phoenix configuration docs. Using PostgreSQL moves the data into a database service your organization already knows how to operate, with its own backup tooling, access controls and monitoring. The Phoenix process can then be restarted, replaced or scaled without touching the stored data.
- Connection setup: Set
PHOENIX_SQL_DATABASE_URLin the deployment configuration, or use the separate connection variables if your secrets tooling stores host, user and password individually. - Backups: Use the backup and point-in-time recovery facilities of your PostgreSQL service, and test restores on a schedule.
- Concurrency: A shared database is the basis for running more than one Phoenix instance behind a load balancer. Confirm the supported topology with Arize's documentation for your version.
- Upgrades: Phoenix schema changes apply to the database, so take a backup and rehearse the upgrade in a non-production copy.
- Access: Restrict database credentials to the Phoenix service account and store them in your secrets manager.
Ask your database team to size storage, connection limits and retention against your own trace volume and retention policy, since these depend on your workload.
The two options differ less in features than in how they are operated. Moving from SQLite to PostgreSQL changes who owns backups, how restores are tested, how upgrades are rehearsed and how credentials are managed. Planning these differences early avoids a storage migration later, which is harder once traces, datasets and prompt versions have accumulated in the first database.
- Ownership: SQLite ties data to one host, while PostgreSQL places it under a database platform team.
- Recovery: A file copy restores quickly on a single node, while PostgreSQL restores depend on the service's backup chain and retention settings.
- Monitoring: PostgreSQL adds connection, disk and query metrics that your monitoring stack should watch.
- Migration cost: Moving data between the two later is a project of its own, so decide the target before production use.
- Audit evidence: Document the chosen storage, backup schedule and restore tests as part of your change records.
Confirm with your security and platform leads which storage model your change process and recovery objectives require.
Storage needs for Phoenix depend on how many traces you record, how large each trace payload is, how long you keep data and how many datasets and experiments you store. None of these figures are supplied here, so treat any estimate you find, including ones in this page, as a starting point to test rather than a planning number. The reliable way to size storage is to measure a representative period of your own traffic.
- Trace volume: Measure requests per day and the average trace size from a pilot run in your environment.
- Payload content: Prompts, completions and retrieved context often dominate size, so capture settings matter.
- Retention: Decide how long traces must remain available, and who approves deletion, before choosing storage.
- Growth: Project storage over the retention window and check disk alerts against that projection.
- Backups: Backup size and restore time grow with the same data, so include them in the sizing exercise.
Ask the Arize documentation team or your own engineers to confirm how the data model grows for your Phoenix version before finalizing the sizing.
What drives the total cost of each option
The first cost line for LangSmith is the commercial relationship itself. Self-hosted LangSmith is an add-on to LangChain's Enterprise plan and needs a license key, so the recurring fee sits with LangChain and is set in your contract, not in a public price list. Ask for the quote to state the base Enterprise fee, whether seats or trace volume are billed, how extended retention is priced, and whether the license covers the Helm or Terraform deployment you plan to run. On the infrastructure side, your Kubernetes cluster, storage and networking are paid to your cloud provider or data center team. Platform engineering time to install, upgrade and keep the stack healthy is an internal cost that recurs for as long as you self-host. Phoenix removes the license line. The self-hosting docs state Phoenix is free to self-host with no feature limitations, no license fees and no usage limits, so the recurring costs shift to what you run. The application server needs compute, and PostgreSQL storage grows with retention, so the retention period you choose for traces and datasets is the main driver of storage spend. Backups and restore tests are part of that bill. Upgrades are the largest ongoing effort: the releases page shows multiple releases per week, so budget for a standing review cycle, a staging environment and a named owner rather than an occasional maintenance window. Internal support and on-call coverage recur whether or not the instance is healthy. Several costs are one-time. Instrumenting applications with OpenTelemetry and OpenInference, exporting and mapping existing LangSmith datasets, and rebuilding evaluations are project costs that fall in the first phase. Confirm with LangChain what your current contract includes for the data export window, because the bulk export plan change affects how much migration work you can do before access ends. A practical check is to model two years of trace volume at your intended retention, then compare that storage and staff time with the quoted Enterprise fee.
How a move from LangSmith to Phoenix works
The sequence takes you from an inventory of LangSmith usage to a Phoenix deployment that runs in parallel with it, then cut over once traces, datasets and evaluations are working. Each step ends with a check you can verify before moving on.
Inventory LangChain and LangGraph usage
Your engineering team lists every place LangSmith receives data: LangChain and LangGraph callbacks, direct SDK calls, custom tracing decorators, online evaluators, annotation queues, prompt hub entries and any CI jobs that run experiments. Map each one to the project it writes to and to the people who rely on it. The output is a written inventory with an owner for each item, reviewed by the team that owns the LLM application. Confirm with your LangChain version and deployment model which integration path applies, since this determines how much code changes.
Export existing trace data
Your platform or data team sets up the LangSmith bulk export to an S3-compatible bucket, which writes trace data in Parquet format. Check the plan on your account first: for customers who signed up after August 3, 2026, bulk export is available only on the Enterprise plan, while earlier Plus customers keep access until February 1, 2027. If your account does not have access, ask LangChain for the export options in writing before you decommission anything. The step is done when a test export lands in your bucket and you can read a sample file with your own tools.
Deploy Phoenix with PostgreSQL
Your platform team deploys Phoenix in your own infrastructure using the Docker, Kubernetes or Helm path that matches your standards. Phoenix starts with a file-based SQLite database by default, which suits a local trial but not a shared service, so configure PostgreSQL through PHOENIX_SQL_DATABASE_URL or the separate connection variables. Set up OAuth2 or LDAP sign-in and role-based permissions, and place the instance behind your network controls. The step is done when the service is reachable only from approved networks, a test trace is stored in PostgreSQL, and the backup job for the database has been tested.
Re-instrument with OpenTelemetry and OpenInference
Your application engineers replace LangSmith tracing with OpenTelemetry and OpenInference instrumentation so spans are sent to Phoenix. Remove or disable the LangSmith tracing environment settings in each service, and keep the instrumentation in one shared module so every service sends the same attributes. Tag prompt versions, model names and user or session identifiers consistently, because these are what let you compare behavior across the move. The step is done when a representative request from each service appears in Phoenix with the expected span tree, model and token data.
Rebuild datasets and evaluations
Your ML or QA team recreates the datasets exported from LangSmith as versioned datasets in Phoenix, using the exported Parquet data as the source. Rebuild each LLM-based evaluator, online or offline, and the experiments that gate releases, then compare results on a fixed set of examples against the LangSmith output. Record which evaluators have no direct equivalent so the team knows what must be redesigned rather than copied. The step is done when each critical evaluator runs in Phoenix and its scores have been reviewed against known good and known bad examples.
Run both platforms in parallel
For a defined period agreed by the team, send production traces to LangSmith and Phoenix at the same time. Compare trace completeness, latency overhead, evaluator scores and alert behavior, and log every gap in a shared tracker with an owner. Check that PHI, personal data or confidential prompts are handled under the same controls in Phoenix as they were in LangSmith. The step is done when the gap tracker has no open items that block production use and the people who review traces agree that Phoenix shows what they need.
Cut over and retire LangSmith
Your team switches the production instrumentation to Phoenix only, keeps the LangSmith project read-only for the agreed retention period, and updates runbooks, dashboards and on-call procedures. Confirm that all exported data is stored in your own bucket under your retention policy, and confirm that the LangSmith account and any API keys are closed or rotated. Before you standardize on Phoenix, have legal or your compliance lead read the Elastic License 2.0 terms, because ELv2 prohibits offering Phoenix to third parties as a hosted or managed service and restricts circumventing license key functionality. The step is done when the license review is recorded and LangSmith is no longer receiving production data.
Questions buyers ask before choosing Phoenix or LangSmith
Can we self-host LangSmith without an enterprise contract?
No. Self-hosted LangSmith is an add-on to LangChain's Enterprise plan and requires a license key. It deploys to your own Kubernetes cluster using Helm charts, with Terraform also documented, so the deployment itself stays in your infrastructure, but the license is a commercial agreement. Ask LangChain for the written terms of the Enterprise add-on, including how the license key is validated, what happens when it expires and which support tier is included. If your requirement is self-hosting without a license key, Phoenix is the closer fit, subject to the licensing terms covered in the next question.
Is Phoenix free to run in production?
Phoenix's self-hosting documentation states it is free to self-host with no feature limitations, no license fees and no usage limits, and that traces, prompts and data stay in your infrastructure, including in air-gapped deployments. That covers the software cost. Production still carries infrastructure, storage, access control, backup, upgrades and on-call ownership, which your team or a partner must cover. Phoenix starts with a file-based SQLite database by default, so a production deployment will usually move to PostgreSQL. Confirm with Arize which features you need in production and whether any of them are offered only through Arize AX, since that managed platform is a separate commercial product.
Can we offer Phoenix to internal teams and external customers under ELv2?
Internal use is the common case, and ELv2 generally permits it, but you should confirm the terms against the license text with your legal team. Phoenix is licensed under the Elastic License 2.0, which is source-available and not OSI-approved. It forbids providing the software to third parties as a hosted or managed service, and it forbids circumventing license key functionality. Running Phoenix so your own business units use it for their own applications is a different situation from offering Phoenix tracing as a service to customers. If your product exposes observability to external parties, get written legal review before you build on Phoenix, or choose an OSI-licensed option such as Langfuse, which is open core, or Opik, which is Apache-2.0.
How much effort is re-instrumenting an application for Phoenix?
The effort depends on how many services emit traces and how they are instrumented today. Phoenix is built on OpenTelemetry and uses OpenInference instrumentation, and the README states that the same instrumentation works with both Phoenix and the managed Arize AX platform. That helps if you already use OpenTelemetry. Teams that rely on LangChain or LangGraph callbacks will need to change how spans are created and exported, and any custom metadata, session IDs and user attributes must be mapped again. Ask for an inventory of services, the instrumentation libraries in use and a list of trace attributes your dashboards depend on before estimating the work in a written scope.
How long does a LangSmith to Phoenix migration take, and what drives it?
No general duration is supplied for this migration, so treat any figure you hear with caution and ask for one in a written scope. The main drivers are the number of applications and environments, how many datasets and evaluators must be rebuilt, the volume of historical traces you need to keep, and whether prompts move with their versions. Historical data is a special case: LangSmith's bulk export writes trace data to an S3-compatible bucket in Parquet format, but for customers who signed up after August 3, 2026, that export is only available on the Enterprise plan, while earlier Plus customers keep access until February 1, 2027. Check your plan and export before you plan the cutover, because the export window affects what you can carry over.
What must our engineers own after a Phoenix go-live?
After go-live, your team owns the running service, not only the code. That includes the Phoenix deployment on Docker, Kubernetes or Helm, the database (SQLite for tests, PostgreSQL for production, configured through PHOENIX_SQL_DATABASE_URL or separate connection variables), TLS, backups, upgrades and retention of trace data. Phoenix supports OAuth2, LDAP and local accounts with role-based permissions, so identity integration and access reviews also fall to you. Phoenix releases are frequent, with arize-phoenix v20.23.0 published on October 16, 2026, so plan a regular upgrade and regression check cycle. Ask a partner to document these tasks in a runbook as part of the scope.
Can our own engineers do the migration without outside help?
Often yes, if you have engineers who already run Kubernetes or Docker services, know OpenTelemetry and can own a database. Phoenix is free to self-host and its documentation covers terminal, Docker, Kubernetes, Helm and several cloud templates, so the first deployment is not difficult in itself. The harder parts are the migration of datasets and evaluations, security hardening, integration with your identity provider and the operating model afterwards. If internal capacity is limited, DeployOpen can plan, implement, integrate, harden, back up, document and support a self-hosted platform inside your own infrastructure under a fixed-scope written agreement. Ongoing support and upgrades are available as retainers. We do not publish a price list, and a quote follows from the scope.
Official sources to check before deciding
Before you commit to Phoenix or to LangSmith, read the primary sources yourself, because the licensing and feature answers decide the project. Start with the Elastic License 2.0 text in the Arize-ai/phoenix LICENSE file. Check two clauses in particular: the prohibition on providing the software to third parties as a hosted or managed service, and the prohibition on circumventing license key functionality. Have legal counsel confirm what those clauses mean for your planned use, such as an internal platform team serving several business units, or a managed offering you might run for a client.
Next, read the Phoenix self-hosting docs at Phoenix self-hosting docs and the Phoenix configuration docs. Confirm the storage backend you intend to run, since Phoenix defaults to a file-based SQLite database and supports PostgreSQL through connection settings such as PHOENIX_SQL_DATABASE_URL. Confirm the authentication setup you need, including OAuth2, LDAP or local accounts with role-based permissions, and test those against your identity provider. The Phoenix README and the Arize-ai/phoenix releases page show which features are current. Releases ship often, so pin a version and review the release notes before each upgrade.
For the LangSmith side, read the LangSmith self-hosting docs and the LangSmith bulk data export docs. Ask LangChain in writing which plan, license and region terms apply to your organization, including whether self-hosting requires an Enterprise license key and whether bulk export remains available on your plan. Verify current license terms and feature availability with each vendor before any purchase or rollout, and record the answers with dates, because both products change.
How DeployOpen helps evaluate, implement or migrate
DeployOpen, a Chainscore Labs company, plans, implements and supports self-hosted open-source platforms inside your own infrastructure. For LangSmith vs Arize Phoenix, we start with a written scope that tests whether Phoenix's Elastic License 2.0 terms, storage choice and tracing approach fit your organization before any build begins.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts
- We map which LangSmith traces, datasets and prompts must move, and which can be re-created
- We review the Elastic License 2.0 terms against how your organization plans to use Phoenix
- A written scope lists which LLM frameworks and tracing libraries need OpenTelemetry or OpenInference instrumentation
How we build
- We deploy Phoenix in your environment using the terminal, Docker, Kubernetes or Helm options you choose
- We choose between the default SQLite database and PostgreSQL based on your volume and operations standards
- We configure OAuth2, LDAP or local accounts with role-based permissions for your teams
- We instrument applications and document the trace, evaluation and prompt management workflows
How we hand over
- We deliver architecture notes, configuration records and runbooks covering deployment, storage and access
- We document what was rebuilt, what was retired and which LangSmith features have no direct equivalent
- We walk your engineers through tracing, evaluations and prompt versioning in your own environment
- We provide a clear list of items for your legal team to confirm against the Elastic License 2.0 terms
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover
- We can track Phoenix releases and plan upgrades on a schedule agreed with your change process
- Security testing of the deployed platform and its integrations can be scoped as a separate engagement
- Compliance readiness work prepares documented controls and evidence, while independent auditors issue any assessment
