How to export your data from Arize

Arize AX exposes its data through two documented paths: an export button that generates a Python snippet and the Python export client that returns pandas DataFrames. This guide covers what you can pull, what you cannot, and how to plan the move before the contract ends.

Book a callTalk to us
On this page

How to export your data from Arize before your contract ends

If a renewal, price change or residency requirement has started your exit plan, you need production traces, datasets and embeddings out of Arize AX. Arize documents two export paths: an export button on the Embeddings, Datasets and Performance tracing pages that generates a Python snippet for a selected date range, and direct queries through the Arize Python export client. Plan on rebuilding some content rather than exporting it, and confirm the full scope of what can leave the platform with Arize before you depend on it.

Start with the export button for a small, bounded slice, such as one week of tracing data, and run the generated snippet in a notebook. For larger or repeatable pulls, use the export client's export_model_to_df method, which returns a pandas DataFrame. Arize notes that specifying columns improves query performance, so list only the fields you need, such as span attributes, inputs, outputs and timestamps. Check the export against a sample from the Arize UI before you rely on it, and record the date range and column list so the pull can be repeated.

Expect reshaping work before loading into Langfuse or Opik. Nested span attributes, OpenInference fields and embedding vectors seldom map one to one onto the target data models, so write a transformation step and test it on a sample. Prompt versions, evaluator definitions, annotation queues and alert rules typically need to be recreated by hand, and Arize's export documentation describes analysis in a Jupyter notebook or loading into Phoenix rather than a full configuration transfer. Ask Arize in writing which artifact types it will export and in what format.

What Arize AX data you can export and in what format

This table maps each Arize AX data type to the export method Arize documents and the output you get from it. Read it to decide whether you need the export button for a quick snapshot or the Python export client for a repeatable pull. The main takeaway is that every route needs the same reshaping step before the data loads into Langfuse or Opik.

Data typeExport methodOutput formatWhat to confirm before exporting
Tracing spansExport button on the tracing page, which generates a Python snippet with the selected date rangeGenerated Python code that you run to retrieve the spansDate range limits and maximum rows for your account with Arize
Tracing spans (scripted)Arize Python export client using export_model_to_dfpandas DataFrameQuery size and rate limits for your plan and region
EmbeddingsExport button on the Embeddings page, which generates a Python snippet with the selected date rangeGenerated Python code returning embedding recordsWhether vector columns are included and how they are serialized
DatasetsExport button on the Datasets page or direct query through the Python export clientGenerated snippet or pandas DataFrameWhether dataset versions and example metadata are returned in one pull
Performance viewsExport button on the Performance tracing page with the selected date rangeGenerated Python code that retrieves the underlying dataWhether the view's filters and computed metrics are reproduced by the query
Column selectionSpecify columns in the export callSmaller DataFrame with only the fields you needPer Arize's Export Data API docs, specifying columns improves query performance
Reshaping for Langfuse or OpikPost-processing of the DataFrame in your own scriptsField mapping to trace, observation, dataset item or score recordsField names, nested JSON attributes and timestamp formats in your export

What does not export directly and how to handle each gap

The documented export paths return trace, embedding and dataset records, not the configuration around them. Evaluator definitions, online rules, dashboards, alerts, access settings and annotations each need a separate decision before cutover. The cards below name the gap, the workaround, and where Arize's export documentation stops.

Evaluator definitions

The Export Data API documents trace, embedding and dataset records, not the evaluator prompts, labels or scoring logic attached to them. Scores that already exist in exported data can be kept as values, but the judge templates that produced them are not documented as exportable. Copy each evaluator template from the Arize interface into your prompt repository, record the judge model and version, then rebuild it as a Langfuse LLM-as-a-judge evaluator or an Opik metric. Confirm with Arize whether a template export path exists for your plan.

Online evaluation rules

Online rules decide which production spans get scored and how often. Arize's export documentation does not confirm a way to export these rule definitions, filters or sampling settings. Record each rule's trigger condition, sampling behavior and destination in a table before you disable it in Arize. Recreate the equivalent rules in the target platform, then compare score volumes over a shared period to confirm coverage matches.

Dashboards and saved views

Charts, saved filters and performance views on the tracing pages are not described in the export documentation as portable objects. Screenshot each dashboard that your on-call and product teams rely on, and write down the query, metric and grouping behind it. Rebuild these views in the target platform's dashboards or in Grafana if you already run it for infrastructure metrics. Confirm with Arize whether any dashboard definition can be retrieved programmatically.

Alert configuration

Alert thresholds, notification channels and escalation targets are configuration, and the export documentation does not describe exporting them. Missing alerts are a cutover risk because nothing fails visibly when a rule disappears. Inventory every active alert, its threshold, recipient and owner, then recreate them in your alerting stack and run both systems in parallel until the new alerts have fired in a test. Confirm the Arize alert list through its interface before you disable anything.

Users, roles and access settings

Space members, roles and SSO group mappings are administrative settings, and Arize's export documentation covers trace and dataset data only. Access in the target platform is set up separately, so the mapping must be written out by hand. Export the user list and role assignments from the Arize admin screens, map each role to a target role such as the Langfuse project roles, and check which features need a license key. Keep a record of who had access to which projects for your audit trail.

Annotations and human labels

Human feedback, labels and annotation queues on spans are the data most likely to matter for future evaluation work. The Export Data API documents span and dataset exports, but it does not confirm that annotation records come back in the same export. Test one annotated span end to end before the full export, check whether the label appears in the output, and if it does not, export the annotations through the interface and load them as a separate dataset keyed by span ID.

Export sequence and verification steps

This sequence turns scattered Arize AX data into a dated, checksummed set of files that you can reconcile against the Arize UI before any data is loaded into a new platform. Each step produces a record you can hand to a reviewer or auditor.

  1. Inventory projects, models and date ranges

    Before exporting anything, list every Arize project, model and dataset that holds data you need to keep, along with the date range each one covers and the owner who can confirm it. Record this in a plain inventory file that names the Arize space, the project, the table type (tracing, embeddings or datasets) and the retention window your organization requires. Done means every in-scope item has an owner and a date range, and nobody is still relying on an unlisted project.

  2. Freeze a cutoff date for each source

    Choose one cutoff timestamp for the whole export and write it into the inventory. Records that arrive after the cutoff belong to a second, incremental run, so the first export does not drift while it is being pulled. Done means the cutoff is documented, agreed with the team that still writes traces to Arize, and used as the end of every date range in the export commands.

  3. Run the export per project with selected columns

    For each project, run either the export button snippet from the tracing, embeddings or datasets page, or the Arize Python export client calling the export_model_to_df method. Specify the columns you need, since Arize documents that choosing columns improves query performance, and keep one script per project so runs can be repeated. Done means each project has a DataFrame or file for its date range, and the run log records the command, the cutoff and the operator.

  4. Store raw output with checksums and row counts

    Write each export to an immutable location before any reshaping, using a naming pattern that includes project, date range and run timestamp. Generate a SHA-256 checksum for every file and record the row count and column list in a manifest. Keep the export script and its version alongside the data. Done means a second person can recompute the checksums and get the same values from the stored files.

  5. Verify a sample against the Arize UI

    Select a sample of traces from the exported set, covering several days and at least one error or long-latency case, and find the same records in the Arize UI using their trace or span identifiers. Compare timestamps, model names, token counts and the key input and output fields. Done means every sampled record matches, and any mismatch is logged with its identifier and resolved before you continue. Confirm with Arize how the UI and the client treat timezones, since a day boundary error is a common source of mismatch.

  6. Confirm row counts per day

    Group the stored files by calendar day in the timezone you chose and compare each daily row count with a count taken from Arize for the same window. Investigate any gap, duplicate or unexpected zero day before accepting the export. Done means every day in the range has a recorded count that matches the source, and the reconciliation sheet is signed off by the data owner.

  7. Stage in Jupyter or Phoenix before loading

    Arize documents that exported data can be analyzed in a Jupyter notebook or loaded into Phoenix, so use one of these as an intermediate workspace. Reshape the verified files there, check that fields such as span hierarchy, prompts and evaluation scores survive, and only then prepare the load into Langfuse or Opik. Done means a reshaped copy exists alongside the untouched raw files, and the notebook or Phoenix instance is documented as a working copy rather than the system of record.

What has to be reshaped before loading into Langfuse or Opik

The DataFrames returned by the Arize Python export client carry Arize's own column layout, so they cannot be loaded into Langfuse or Opik as they are. The first decision is the target model. In Langfuse, each step of an LLM call becomes an observation, and traces group those observations. In Opik, traces and spans play those roles. Map each Arize span row to one of these records, and keep parent-child relationships intact so the call tree still renders. Then map the token and cost fields. Confirm which Arize columns hold prompt tokens, completion tokens and cost, and whether the target recalculates cost from its own model price tables or accepts the stored values. Timestamps need the same care: check whether the export returns UTC or local time, and convert every start and end time to one zone before loading, or durations will look wrong in the target UI.

Input and output payloads are the most common source of silent loss. Arize stores them in its own attribute structure, often as nested JSON or flattened attribute names, so validate a sample of rows against the source before you write a bulk loader. Identifiers matter just as much. If datasets, evaluation scores or experiment runs refer to trace or span IDs, build a crosswalk table that maps each Arize ID to the new Langfuse or Opik ID before anything is imported. Without that table, scores and dataset items lose their links to the traces they describe. Also decide up front which evaluator results to carry over as scores and which to recompute, because recomputed scores will not match historical ones unless the judge model and prompt are identical.

For new data, the cleaner path is instrumentation, not backfill. Langfuse supports ingestion over OpenTelemetry, and Opik supports OpenTelemetry alongside its native SDK integrations, so new production traffic can be sent to the self-hosted platform while the Arize export covers history. Confirm the current OpenInference-to-OpenTelemetry attribute mapping for your framework with each vendor, and test it in a non-production project first. No ready-made importer from Arize exports to either platform has been confirmed here, so plan for a script you write, test and version-control, and reconcile record counts per day between source and target before you retire the Arize project.

Choosing the target for the exported data

Langfuse is open core. Code outside its ee directories is MIT licensed, and Langfuse states that all core features and APIs are available in the open-source version without limits. Some advanced capabilities, such as project-level RBAC roles, audit logs, data retention policies and SCIM, need an enterprise license key. A self-hosted deployment runs Langfuse Web and Langfuse Worker, plus PostgreSQL, ClickHouse, Redis or Valkey, and S3-compatible blob storage.

  • Documented minimums: the Langfuse scaling guide lists 2 CPU and 4 GiB each 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.
  • Upgrade headroom: 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.
  • Ingestion scaling: under heavy ingestion, Langfuse recommends splitting langfuse-web into separate ingestion and user interface deployments.
  • Deployment shape: Docker Compose on a single VM is documented for testing without high availability, while Kubernetes with Helm or Terraform is the production path.

Confirm the ClickHouse sizing against the retention window you need and the backfill volume from Arize before you commit to a storage tier.

Questions teams ask before exporting data from Arize

How much effort does exporting data from Arize take?

The effort depends on how much data you pull, how far back you need it, and how much reshaping the target platform requires. Arize documents two routes: an export button on the Embeddings, Datasets and Performance tracing pages that generates a Python snippet for a selected date range, and direct queries through the Arize Python export client. The button route is quick for a one-off pull. Bulk history, multiple projects and schema mapping take longer. Reshaping is usually the largest piece: the export_model_to_df method returns a pandas DataFrame, and Arize notes that specifying columns improves query performance, so you should decide which fields your Langfuse or Opik import needs before you run large queries.

Can our team export the data without outside help?

Often yes, if you have a Python engineer who can run the export client and someone who understands your trace schema. The export itself is a scripted query, so the harder work sits in mapping Arize fields to the structure your new platform expects. Ask yourself whether anyone on the team has written an ingestion script, can validate row counts, and can explain which records contain personal or customer data before they leave Arize. If those skills are thin, a fixed-scope engagement with DeployOpen can cover planning, the export scripts, the reshaping and the load into a self-hosted target, with the scope agreed in writing first.

What does the export need from our side?

Plan for four inputs before work starts:

  • An Arize API key with permission to read the projects, datasets and embeddings you want to export
  • A storage location for the extracted files, such as an encrypted volume or your own object store
  • Target capacity on the platform you load into. Langfuse self-hosting depends on PostgreSQL, ClickHouse, Redis or Valkey, and S3 or blob storage, and its scaling guide lists minimum resources of 2 CPU and 8 GiB for ClickHouse, with at least 16 GiB of ClickHouse memory for larger deployments
  • A named owner who approves the data scope, the retention window and the cutover date

Confirm each item with your security team, since exported traces may include prompts and user content.

How long does an Arize data export take?

The duration depends on the number of traces, the date range, the number of projects and how many fields you extract. Arize does not publish a throughput figure in the material we rely on, so measure it: run the export for one project and one week of data, time it, then scale. Plan separately for reshaping and for loading into the target, which often takes longer than the pull itself. Ask Arize to confirm any rate limits or query size limits for your account in writing before you schedule a large run.

Is Arize data export included in our plan?

This is a question for Arize, and the answer determines whether you can plan a bulk export without a contract change. The export methods in the Arize documentation are described on the Export Data API page, but plan entitlements, data retention limits and any charges tied to querying history can differ by contract. Ask your account team to state in writing whether the export client and the export button are covered under your current agreement, what retention window applies to the data you need, and whether any extra fees apply to large queries.

What should we confirm with Arize in writing before we start?

Get written answers on five points:

  • Which export methods and API versions your contract covers, including the Python export client
  • The retention window for each project, so you know how much history actually exists
  • Any rate limits, query size limits or fees for large or repeated exports
  • Where exported data is processed and whether any copy stays on Arize's side after you delete it
  • Support contacts for export failures during your migration window

Keep the answers with your migration record, since they shape scope, timing and your data handling statement.

Can exported Arize data be loaded straight into Langfuse or Opik?

Not without reshaping. Arize documents that exported data can be analyzed in a Jupyter notebook or loaded into Phoenix, but Langfuse and Opik each define their own trace, observation and dataset structures. Expect to map span identifiers, parent and child relationships, timestamps, token usage, model names and evaluation scores into the fields each target expects. Opik supports OpenTelemetry and offers a @track decorator for custom code, and Langfuse documents OpenTelemetry ingestion, so a short mapping layer that writes through those interfaces is usually easier to test than a direct database load. Validate a sample of traces end to end before any bulk import.

What to plan before the Arize contract renewal or termination

Export is the last step of a migration, so the decisions that matter come first: what Arize will hand over and by when, where the data will land, and who verifies it. The cards below follow the order most teams work through these choices before the notice date arrives.

Confirm export scope and deadline in writing

Ask Arize, in writing, which data is covered by an export: traces, embeddings, datasets, evaluations and annotations, and for what date range. Ask for any retention or deletion deadline that applies after your contract ends, and whether the export is included in your plan or billed separately. Verbal assurances rarely survive a renewal dispute, so the answers should be in the contract file before you plan the cutover.

Choose the target platform and its license

Decide the license before you decide the tool. Phoenix is licensed under the Elastic License 2.0, which is not OSI-approved and bars offering the software to third parties as a hosted service. Langfuse core is MIT licensed, with enterprise directories under a separate license, and Opik is Apache-2.0. Pick the target that matches how your organization will use it, and confirm the terms with your legal team.

Size self-hosted storage before loading

Estimate the storage your retention window needs before you load history, since the export is only useful if the target can hold it. Langfuse self-hosting depends on ClickHouse for analytical storage, PostgreSQL, Redis or Valkey, and S3-compatible blob storage, and Langfuse advises keeping roughly 3x ClickHouse disk headroom when backfilling historic data. Opik uses ClickHouse, MySQL and Redis. Ask your platform team to size these components against the exported volume, not against current daily traffic.

Run tracing in parallel during cutover

Keep Arize receiving traces while the new platform goes live, so production monitoring never has a gap. Point a copy of your OpenTelemetry or OpenInference exporter at the new backend first, compare trace counts and spans for a sample of requests, and only then switch the primary exporter. Plan for a period where both systems hold overlapping data, and decide which one your on-call engineers check during incidents.

Schedule the export before the notice date

Run the bulk export well before the date your contract or Arize's retention rules require, because a failed or partial pull leaves little time to repeat it. Confirm the date in writing, then build a timeline backward from it that includes script testing on a small date range, the full pull, reshaping and loading, and a spot check. Note that the Python export client returns pandas DataFrames, so specify only the columns you need to keep queries fast on large ranges.

Assign verification and deletion sign-off

Name the person who signs off that the exported data is complete and that Arize-held copies can be deleted. Verification should compare record counts, date ranges and a sample of trace content against the source, and be documented. Deletion should follow your data retention policy and be confirmed in writing by Arize, since copies may persist in backups or downstream tools. Without a named approver, the deletion step often gets skipped during renewal.

Running Arize and the new platform in parallel

Run Arize AX and the new platform side by side for a defined overlap period so that a broken exporter or a missing field shows up while Arize is still the system of record. The main risk in this migration is not the export itself but a gap in trace coverage after cutover, and a parallel period is the cheapest way to detect it. During the overlap, point the instrumentation at both systems: the OpenTelemetry or OpenInference exporter that already sends spans to Arize should also send them to the new backend, such as self-hosted Langfuse or Opik. Confirm in your own environment that the second exporter does not block the application path if the new endpoint is slow or unavailable, since a failed secondary export should never fail a user request.

Keep the historical exports from the Arize export button or the export_model_to_df method as the system of record until the new platform has been checked against them. Store each export with its date range, the selected columns and the export timestamp, so that a later question about a specific day can be answered from a fixed file rather than by re-querying Arize. Then compare trace counts per day between Arize and the new platform for the same window. Count by day rather than by total, because a day-level gap points to a specific deployment, job or sampling change, while a total hides it. Differences in span counts can come from sampling, retries or how each system groups spans into traces, so document the expected difference before you treat any mismatch as a defect.

Decide in advance what counts as a passing comparison and who signs it off, and record that decision with the export files. Ask the Arize account team and the new platform's maintainers to confirm which fields, retention windows and ingestion limits apply to your plan or deployment, because those settings determine whether older days can still be reproduced after Arize access ends. Once the daily counts match within the agreed tolerance, switch the primary read path, keep the secondary exporter for a rollback window, and then remove the Arize exporter from production configuration.

How DeployOpen scopes and delivers an Arize data export

DeployOpen treats an Arize data export as a fixed-scope engagement: we agree in writing which tracing, embeddings and dataset data leaves Arize, in what shape, and where it lands. We then build and test the extraction and the load into a self-hosted target such as Langfuse or Opik, and hand over documentation your team can rerun.

How we scope

  • Inventory which tracing, embeddings and dataset views hold the data you need to keep
  • Agree the date range, column list and row volumes that the export must cover
  • Confirm the target platform, whether Langfuse or Opik, and where the exported data will be stored

How we build

  • Write Python export scripts against the Arize export client that return pandas DataFrames
  • Reshape columns, timestamps and nested fields into the schema the target platform expects
  • Test a sample load into a non-production instance and reconcile record counts against the source

How we hand over

  • Document the export steps, column mappings and reshaping rules so they can be rerun
  • Deliver the scripts and configuration in your repository, with notes on each assumption
  • Walk your engineers through the load process and the checks used to confirm completeness

How we support

  • Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts
  • Ongoing support, upgrades and continuous testing are available as a retainer
  • Ask for a quote based on the written scope, which covers data volume, target platform and reshaping effort

Related

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.
Book a callhello@deployopen.com