How to plan the Langfuse v3 to v4 upgrade on infrastructure you control
The supported path runs from the latest v3 release, through finished background migrations, into v4 in a temporary legacy or dual write mode, and then to cutover. If your team runs self-hosted Langfuse v3 and needs v4 for its data model or SDK support, plan the change as a major upgrade. Langfuse publishes a dedicated migration guide for v3 to v4, and it does not treat this step like an in-version update, which applies database migrations automatically at startup. Use the current release line, v4.63.0 (published October 16, 2026), as the target to test against, and confirm the latest patch in the Langfuse releases page before you fix a date for the rehearsal.
Plan the work inside the environment you operate, whether that is a cloud account, a data center or an air-gapped network. A self-hosted deployment runs Langfuse Web, Langfuse Worker, PostgreSQL, ClickHouse, Redis or Valkey, and S3-compatible blob storage. The v4 guide requires ClickHouse 25.12 or later (26.4 is recommended), PostgreSQL 15 or later and Redis 7.0 or later. Compare these minimums with your current versions and your change calendar for each component. In an air-gapped network, also confirm that you can mirror the new container images and chart versions into your registry before the window opens. If you use the Helm chart with bundled data stores, the chart must move from v1 to v2 before Langfuse moves to v4, so that step belongs early in the plan.
Make three decisions before any production change. First, confirm that you are on the latest v3 release and that every v3 background migration has finished, because v4 schema migrations drop tables that v3 superseded. Second, choose the temporary value for LANGFUSE_MIGRATION_V4_WRITE_MODE, either legacy or dual write, and record why. Third, decide how long the instance stays in that mode before cutover. The default events_only mode applies after cutover, and the migration modes exist only to bridge the change, so write down the exit criteria for leaving them. Rehearse each decision on a restored copy of your production data in a non-production environment that matches the target sizing.
What changes in Langfuse v4 and what each change asks of your team
This table lists each change between Langfuse v3 and v4 that affects a self-hosted deployment, what it means for operations and data, and the action your team needs to take. Read the rows before the cutover plan is written, because several changes stop existing integrations at cutover. The main takeaway is that the data model, ingestion, evaluator, export and SDK changes each need a named owner before the upgrade window opens.
| Change | Impact | Action needed |
|---|---|---|
| Observations-first ClickHouse data model | Trace and observation data is organized around observations, so queries and reports built on the v3 layout need review | Confirm ClickHouse 25.12 or later (26.4 recommended) and plan about 3x ClickHouse disk headroom for backfill |
| Temporary legacy and dual write modes (LANGFUSE_MIGRATION_V4_WRITE_MODE) | Chosen at startup and meant only for migration; events_only is the default after cutover | Choose the mode deliberately, record it in the change plan, and name who decides when to cut over |
| Superseded v3 tables removed by v4 schema migrations | Tables superseded during v3 are dropped when the v4 schema migrations run | Run the latest v3 release and confirm all background migrations have finished before upgrading |
| Legacy batch ingestion at /api/public/ingestion | After cutover, returns 400 for every event type except score-create | Find every sender on this endpoint and move it to current SDKs or the OpenTelemetry endpoint |
| Trace-level and legacy-dataset LLM-as-a-Judge evaluators | Stop running after cutover | Inventory evaluators and rebuild each one on a supported path before cutover |
| Legacy traces and observations export source | Stops producing data after cutover | Repoint scheduled exports and downstream reports to the current export source and test them |
| Helm chart move from v1 to v2 for bundled data stores | Required before upgrading to v4 for Helm users with bundled data stores | Plan the chart upgrade as a separate step ahead of the Langfuse v4 upgrade |
| SDK floors: Python SDK v5 and JS/TS SDK v6 | Need Langfuse v4.59.0 or later | Inventory SDK versions in each application and sequence SDK upgrades with the server upgrade |
Why the observations-first data model changes the Langfuse v3 to v4 upgrade
The observations-first data model changes what your ClickHouse data is organized around. In v4, the observation (a span, generation or event recorded inside a trace) becomes the record that queries, dashboards and exports are built on, rather than the trace-level shape many teams query today. For a team that stores traces in ClickHouse, this is a data model change that needs its own review, not a routine version bump. Before planning cutover, have your data owners list the tables, fields and joins their current queries depend on, then confirm with the v4 migration guide which of them are replaced, renamed or derived differently.
The downstream effects reach further than Langfuse itself. Dashboards in Grafana, Metabase, Superset or any other BI tool that query ClickHouse directly will need their SQL checked against the new shape. Scheduled exports, data warehouse loads, cost reports, alert rules and internal scripts that read legacy trace and observation fields are all exposed. After cutover, the legacy traces and observations export source stops producing data, and legacy batch ingestion at /api/public/ingestion returns 400 for every event type except score-create. A consumer that fails quietly can go unnoticed for days, so each one should have an owner and a test that confirms it still receives data.
Historic data needs space to be reshaped. The v4 migration guide advises about 3x ClickHouse disk headroom when backfilling historic data. As an illustration only, if your existing ClickHouse data occupies 1 TB, the guide's advice would call for about 3 TB of free disk during the backfill. Confirm with the vendor guide how the backfill is scheduled, whether it can run while ingestion continues, and how long dashboards may show incomplete history. Ask your ClickHouse operators whether the free space is available on every node or shard, because a backfill that runs out of space partway through is a common failure to plan around.
Turn these points into decisions before the build starts. Choose whether dashboards and exports are rebuilt against the observations shape before or after cutover, and whether a parallel comparison of old and new query results runs in a staging copy first. Confirm which LLM-as-a-Judge evaluators are trace-level, since those stop running after cutover and will need a replacement path. Record the retention decision for legacy history so that the backfill and disk plan match what you keep. These choices shape the write mode you select and the cutover window, so settle them with the data owners and platform team together.
Preparation before the Langfuse v3 to v4 upgrade starts
Most problems in a v4 upgrade trace back to work done before the upgrade window opens. The cards below cover the entry gates Langfuse sets, the infrastructure floors, the backups and the inventory of callers that will need changes at cutover. Treat each one as an entry criterion and record the evidence in your change ticket.
Reach the latest v3 release
Langfuse requires you to move to the latest v3 release before starting the v4 upgrade. Confirm the running image tag for both Langfuse Web and Langfuse Worker, then check that every background migration has reported as finished. This matters because v4 schema migrations drop tables that v3 superseded, so a migration still running during the upgrade can leave data in an unexpected state. Record the version and migration status as evidence.
Meet the database version floors
The v3 to v4 guide requires ClickHouse 25.12 or later, with 26.4 recommended, PostgreSQL 15 or later and Redis 7.0 or later. Check the current version of each component in every environment, including Redis or Valkey and any managed services, because a version that works for v3 may fall below the floor. Plan any database version upgrades as separate changes with their own rollback, so a failed database step does not get mixed into the Langfuse change.
Check resources against the scaling baseline
Langfuse's scaling guide lists minimums 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. Treat these as a floor, then compare them with observed CPU, memory and ingestion load over a representative period. The guide also advises about 3x ClickHouse disk headroom when backfilling historic data, so size storage before the backfill starts.
Back up all three data stores
Take backups of ClickHouse, PostgreSQL and the S3-compatible blob storage before any upgrade step runs. The three stores hold traces, metadata and uploaded media that must stay consistent with each other, so record a matching restore point for each. Test that each backup restores to a working instance, and do not rely on a job status alone. Agree in advance who can authorize a restore and where the restore will run.
Inventory every API caller
List each SDK, evaluator, export job and integration that calls the Langfuse API. Record the Python SDK and JS/TS SDK versions in use, since the v4 path needs Python SDK v5 and JS/TS SDK v6 on Langfuse v4.59.0 or later. Flag any caller that posts to the legacy batch ingestion endpoint, runs trace-level LLM-as-a-Judge evaluators or reads the legacy traces and observations export, because each of these changes or stops at cutover. Assign an owner to every item.
Build a staging environment at production scale
Stand up a staging copy that matches production in version, topology and data volume, because backfill time, disk growth and query behavior depend on how much history exists. Restore from a recent backup, then run the v4 migration there first using the same write mode and configuration you plan to use in production. Use the staging results to set the production window and to test rollback. Keep staging secrets and blob access separate from production.
The Langfuse v3 to v4 upgrade sequence with checks and rollback points
This sequence moves a self-hosted Langfuse deployment from v3 to v4 in an order that keeps data recoverable at each stage. Each step closes with a check, and each names the point up to which rollback is practical.
Confirm v3 is current and migrations are finished
Your platform team first moves the existing deployment to the latest v3 release. They then confirm that all background migrations have finished, because v4 schema migrations drop tables that v3 superseded, and a pending migration would be left behind. The step is done when no migration is pending or failing and the worker logs show no errors from migration jobs. Rollback at this point means returning to the v3 release you started from, and you should confirm the exact procedure with the vendor migration guide.
Verify database versions and disk headroom
Your infrastructure team checks ClickHouse, PostgreSQL and Redis or Valkey against the v4 requirements: ClickHouse 25.12 or later (26.4 recommended), PostgreSQL 15 or later and Redis 7.0 or later. They also size ClickHouse disk for the backfill, which the vendor guide says should leave about 3x the current data footprint free. The step is done when a written version inventory matches the requirements and the free disk figure is recorded. Any gap must be closed before the next step, because a version or disk shortfall found during backfill is the hardest failure to reverse.
Upgrade the Helm chart from v1 to v2
This step applies only if you run Langfuse on Kubernetes with the bundled PostgreSQL, ClickHouse, Redis or blob storage charts. Your platform team upgrades the Langfuse Helm chart from v1 to v2 before any change to the application version, using the chart's own migration notes and a review of the rendered values. The step is done when the chart reports v2, the existing pods and data stores are healthy, and v3 still serves traffic normally. If you use external data stores, record that this step is not applicable and move on. Rollback is the previous chart release, and you should confirm its exact procedure with the vendor guide.
Take and verify backups of all stores
Your operations team takes a backup of PostgreSQL, ClickHouse and blob storage, and records the Helm values and the image tags in use. The backup is not complete until someone restores it to a separate environment and checks that the Langfuse instance starts and that recent traces and prompts are present. The step is done when that restore test passes and the backup location, retention and access are recorded. This is the most important rollback point: from here, a verified backup allows the team to return to v3 with a known data state, so do not start the write mode change until it is confirmed.
Set write mode and test v4 in staging
Your engineers set LANGFUSE_MIGRATION_V4_WRITE_MODE to legacy or dual, choosing the mode that matches your ingestion and evaluator needs, and deploy v4 to a staging environment that mirrors production. They then run ingestion tests from representative SDKs and LLM-as-a-Judge evaluator tests, and compare results with v3 output. The step is done when test traces, scores and evaluator results appear as expected and no ingestion errors occur. While the mode is legacy or dual, rollback to v3 remains practical, but confirm the procedure for your chosen mode with the vendor migration guide before production go-live.
Run the backfill of historic data
Your team runs the backfill that moves historic data into the observations-first ClickHouse model, starting in staging so the duration and resource use can be observed before production. They watch ClickHouse disk usage, memory and query performance during the run and confirm the backfill is progressing as the vendor guide describes. The step is done when the backfill completes without errors and spot checks of historic traces, observations and scores return the same results as in v3. Stop and investigate if disk headroom falls toward the planned limit, since the backfill is the step where storage pressure is most likely.
Move SDKs to the supported versions
Your application teams upgrade their SDKs to the versions that support Langfuse v4: the Python SDK v5 and the JS/TS SDK v6, both of which require Langfuse v4.59.0 or later. They update dependencies, deploy the instrumented services to staging first, and confirm that traces still arrive with the expected structure and that prompt fetching works. The step is done when every service in scope reports traces through the new SDK in staging and production traffic is planned for the same versions. Keep legacy writes working during this step, because services still on older SDKs depend on the write mode you chose.
Cut over to events_only and verify
Your engineers change the write mode to events_only, which is the default after cutover, and restart the affected services. They then verify ingestion, LLM-as-a-Judge evaluators and the exports that your reporting depends on. After cutover, legacy batch ingestion at the ingestion endpoint returns 400 for every event type except score-create, trace-level and legacy-dataset LLM-as-a-Judge evaluators stop running, and the legacy traces and observations export stops producing data. The step is done when the checks pass and downstream consumers have been moved to the new exports. Treat cutover as the point where simple rollback ends, and confirm the exact reversal path with the vendor migration guide before go-live.
Choosing legacy or dual write mode for the cutover window
The write mode you choose sets how much time your teams have between the start of the v4 upgrade and the day ingestion changes. Langfuse v4 starts in either legacy or dual mode, selected with the LANGFUSE_MIGRATION_V4_WRITE_MODE setting. Both modes are temporary. The default events_only mode applies after cutover, so neither mode is a permanent configuration. Record the chosen mode in the change plan before the upgrade starts, and confirm its exact behavior in the Langfuse v3 to v4 migration guide first, because the guide is the authority on which write paths stay open and for how long.
Legacy and dual modes differ mainly in how many write paths run at once. Confirm in the guide whether legacy mode keeps only the v3 batch ingestion path at /api/public/ingestion active, and whether dual mode writes each event into both the old and new data models. That answer drives two costs. Dual writes add work for Langfuse Worker and ClickHouse, so scale the worker on CPU load as the scaling guide recommends. Storage also changes: the guide advises about 3x ClickHouse disk headroom when backfilling historic data, so ask whether that headroom applies during the dual window, during the backfill, or both.
The mode also sets how long old SDK code and evaluators keep working. After cutover, legacy batch ingestion returns 400 for every event type except score-create. Trace-level and legacy-dataset LLM-as-a-Judge evaluators stop running, and the legacy traces and observations export stops producing data. Python SDK v5 and JS/TS SDK v6 require Langfuse v4.59.0 or later, so every application and evaluator owner needs a migration date before cutover. Inventory those owners and their release cycles now, then compare that list with the window the guide allows for each mode.
Choose legacy mode when your SDK and evaluator inventory is small, your backfill capacity is already confirmed, and no downstream team depends on the legacy export. Choose dual mode when many services or evaluators need a longer migration window and you can fund the extra compute and ClickHouse storage for the duration. Before either decision is final, ask Langfuse or your implementation partner to confirm the exact window and write behavior for your target version, and put that answer in writing alongside the cutover plan.
What makes the Langfuse v4 upgrade take longer
This table lists the drivers that most often lengthen a self-hosted Langfuse v3 to v4 upgrade, why each one adds work, and what to measure before planning cutover. Read each row against your own environments and history. The main takeaway is that data volume, client count and the ingestion availability target often matter more than the migration steps themselves.
| Driver | Why it adds effort | What to check |
|---|---|---|
| SDK integrations | Python SDK v5 and JS/TS SDK v6 need code and dependency changes, and they require Langfuse v4.59.0 or later. | Count every service and repository that calls the SDKs, their pinned versions, and the owner of each. |
| Custom evaluators and LLM-as-a-Judge | Trace-level and legacy-dataset LLM-as-a-Judge evaluators stop running after cutover, so they must be rebuilt. | List each evaluator, its target (trace or observation), its scoring output and who depends on its scores. |
| History volume | Backfilling historic data takes time and needs extra ClickHouse disk, with about 3x headroom advised during backfill. | Measure current ClickHouse disk use, row counts per table, the retention window and free disk on each node. |
| Bundled or external data stores | Helm users with bundled data stores must upgrade the chart from v1 to v2 before upgrading to v4. | Confirm whether PostgreSQL, ClickHouse and Redis are bundled, the current chart version and drift in values files. |
| Legacy export consumers | The legacy traces and observations export source stops producing data after cutover, which breaks any tool that reads it. | Identify every tool reading that export, its schedule, its replacement source and who owns it. |
| Number of environments | Each environment repeats the background migration check, write mode choice, backfill and validation. | Confirm the promotion order, which environments hold production-like data and which can be rebuilt. |
| Ingestion availability target | Legacy batch ingestion at the old endpoint returns 400 after cutover, so clients still posting there fail. | Agree the availability target in writing, find clients still on the legacy endpoint and set the rollback window. |
| Background migration status | v4 schema migrations drop tables superseded in v3, so v3 background migrations must finish first. | Move to the latest v3 release and confirm in the admin view that all background migrations have completed. |
Which SDKs, evaluators and exports break at cutover
Three groups of integrations stop working or change behavior when a self-hosted Langfuse v3 deployment cuts over to v4: clients that send events to legacy batch ingestion at /api/public/ingestion, LLM-as-a-Judge evaluators configured at the trace level or on legacy datasets, and any job that reads from the legacy traces and observations export source. Inventory all three before you pick a cutover date, because a failure in any of them is silent from the Langfuse UI's point of view unless something in your own monitoring notices. Ask your platform team to confirm which of these paths carries production traffic today, rather than assuming the SDK version alone answers the question. Legacy batch ingestion. After cutover, /api/public/ingestion returns 400 for every event type except score-create. Search your codebase, CI pipelines, notebooks and internal wrappers for direct HTTP calls to that path, and for SDK versions that still post batches there. Python SDK v5 and JS/TS SDK v6 need Langfuse v4.59.0 or later, so confirm each service's pinned SDK version and move it before cutover. Replace any custom batch posting with the SDK's supported calls, and record which services you changed so a rollback plan can account for them. Trace-level and legacy-dataset evaluators. LLM-as-a-Judge evaluators that are scoped to traces or that run against legacy datasets stop running after cutover. In the Langfuse UI and configuration, list every evaluator, its target and its last successful run. For each one that is still needed, recreate it against the supported replacement, then compare scores from a sample of traces before retiring the old definition. Scores written by evaluators are often consumed by dashboards and alerts, so check those consumers too. Legacy traces and observations export. The legacy export source stops producing data after cutover. Find scheduled exports, reporting queries, data warehouse loaders and backup scripts that call it, and move each one to the export path that the upgrade guide names as current. Then run each job once against a non-production copy and confirm row counts and field names match what downstream consumers expect. OpenTelemetry traces. Traces sent to the /api/public/otel endpoint are a separate path from the batch ingestion described above. Do not assume they behave the same way through cutover. Confirm with the Langfuse v4 upgrade guide, and in a staging test, whether OTLP traces are accepted, stored and visible in the new data model during and after the switch, and whether any attributes or observation types change. Treat that confirmation as a gate in your cutover plan.
Testing the Langfuse v4 upgrade and deciding when to roll back
A cutover is safe only when each test has an expected result, each go decision has a named owner, and each stage has a point you can return to. The cards below cover the staging environment, backfill measurements, functional checks, dashboard and export comparison, go and no-go criteria, and rollback points with v3 backups.
Staging seeded with production-shaped data
Build a staging environment that matches production in ClickHouse, PostgreSQL and Redis versions and in the shape of your data: trace volume, observation nesting, score types, prompt versions and evaluator configurations. Confirm that staging runs ClickHouse 25.12 or later (26.4 recommended), PostgreSQL 15 or later and Redis 7.0 or later before you start. Copy a recent snapshot of v3 data, record its timestamp so later comparisons use the same baseline, and approve the copy under your data handling rules if traces contain personal data.
Backfill duration and disk headroom
Run the historic backfill in staging and record how long it takes and how much ClickHouse disk it uses at each stage. The v3 to v4 guide advises about 3x ClickHouse disk headroom when backfilling, so compare peak disk use against that figure and set your go threshold from your own measurements. Ask the vendor or your DeployOpen team whether the backfill can pause and resume and how it reports progress, because those answers determine how long production ingestion is affected.
Functional checks for writes and reads
Write test cases with expected results for score-create, trace ingestion, prompt retrieval and each evaluator your team runs, including LLM-as-a-Judge evaluators. Run them in staging after the write mode is set and record expected and actual output for each. Include legacy batch ingestion, which after cutover returns 400 for every event type except score-create. Trace-level and legacy-dataset LLM-as-a-Judge evaluators stop running after cutover, so list them separately and confirm with the vendor guide what replaces them.
Dashboard and export comparison
Capture the same dashboards, saved queries and exports before and after the migration in staging, using a fixed time window. Compare trace counts, latency, scores and export row counts, and require a written explanation for every difference before the go decision. The legacy traces and observations export source stops producing data after cutover, so any scheduled export or downstream job that reads it must move to a supported source before the change window.
Go and no-go criteria before cutover
Agree a written list of go and no-go criteria with the platform owner, the security lead and the business owners of the traces before a change window is booked. Include the backfill result against disk headroom, functional test results, dashboard and export reconciliation, and the status of a tested backup restore. Name one decision maker for each criterion. An unmet criterion is a no-go unless that decision maker approves an exception in writing.
Rollback point for each stage
Define a rollback point for each stage: before any Helm chart change from v1 to v2 where bundled data stores are used, before the v4 upgrade, after the write mode is set, and after cutover. For each point, record what is restored and which data written in the meantime could be lost. Keep v3 PostgreSQL, ClickHouse and blob storage backups until your team has validated the new data. Confirm the rollback steps after cutover with the vendor upgrade guide before relying on them.
Questions teams ask before upgrading Langfuse from v3 to v4
What does a self-hosted Langfuse v4 upgrade cost, and what drives it?
The cost has four parts: internal engineering time, partner fees if you hire help, infrastructure for the backfill and parallel running, and any Enterprise support tier. Internal time covers planning, SDK and evaluator migration, testing and cutover, and it is mostly one-time. Partner fees follow from a written, fixed scope, so ask for a quote built from that scope. Infrastructure is the cost teams most often underestimate. The v4 migration guide advises about 3x ClickHouse disk headroom when backfilling historic data, and parallel running needs spare capacity for both paths. The Self-Hosted Enterprise plan on Langfuse's pricing page is custom-priced and adds a named support engineer, solutions architect access and a support SLA, so confirm with Langfuse whether you need it. Ask every quote to separate one-time migration work from recurring support.
How long does the upgrade take, and what sets the timeline?
No single duration fits every deployment, so the timeline depends on scope and on your change control. The main drivers are the size of your trace history, since backfill time grows with the data you migrate, and the number of SDK integrations and LLM-as-a-Judge evaluators that need migration and retesting. Change control matters as much: approval steps, freeze periods and the number of cutover windows your organization allows can add more time than the technical work. After cutover, legacy batch ingestion at /api/public/ingestion returns 400 for every event type except score-create, so every client must be migrated before that point. Ask for the timeline in the written scope, with each dependency named.
What does our team need to provide for the Langfuse upgrade?
The work needs access, backups, owners and data. Provide access to the cloud accounts, hosts or clusters that run Langfuse, plus the ClickHouse, PostgreSQL and blob storage it uses. Take and verify database backups before any change, and confirm you can restore them. Name an owner for each integration, including SDK-instrumented applications, OpenTelemetry pipelines, gateways and the identity system. Supply test data that represents real trace shapes and volumes, and a staging environment close to production. If you run the Helm chart with bundled data stores, the chart must move from v1 to v2 before Langfuse moves to v4, so confirm that path in your environment. Agree on change windows early.
Can our own team upgrade Langfuse to v4 without a partner?
Yes, if your team already operates the platform and has time to test. The team needs ClickHouse operations experience, including backups and disk capacity planning, PostgreSQL 15 or later and Redis 7.0 or later, and Kubernetes or Docker Compose operations, depending on how Langfuse is deployed. Someone also needs to manage the Helm chart upgrade where it applies, and to migrate SDKs. Python SDK v5 and JS/TS SDK v6 require Langfuse v4.59.0 or later. The most common constraint is test time, not skill. Each integration needs verification before cutover, and a rollback plan must be rehearsed. If any of these skills are missing, a fixed-scope partner engagement covers the gaps.
Can a partner take over the Langfuse v4 upgrade from start to finish?
Yes. DeployOpen plans, implements, backs up, documents and supports self-hosted open-source platforms in infrastructure you control, and the Langfuse v4 upgrade fits that scope. A typical written scope covers a preflight review, confirming that v3 background migrations have finished, choosing the write mode, migrating SDKs and evaluators, planning and running the backfill, cutover, a rollback plan and handover documentation. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support, upgrades and testing are available as retainers. DeployOpen does not issue audit reports or certifications for the result. Ask for a written scope that names your integrations and your change windows.
Which write mode should we choose, legacy or dual write?
Choose the mode with the LANGFUSE_MIGRATION_V4_WRITE_MODE setting, and treat both options as temporary. Langfuse v4 starts in a legacy or dual write mode, and the default events_only mode applies after cutover. The choice affects how traffic reaches the new ClickHouse data model during the migration window, which changes load, storage and the order in which you migrate clients. Before you decide, read the current v3 to v4 migration guide for the exact behavior of each mode in the version you plan to run, and test both against your staging data. Record the chosen mode, the exit condition and the date you plan to move to events_only in your change plan.
How DeployOpen scopes, delivers and supports a Langfuse v4 upgrade
DeployOpen plans and carries out the self-hosted Langfuse v3 to v4 upgrade inside your own infrastructure, from the ClickHouse, PostgreSQL and blob storage underneath it to the SDKs and evaluators that send and score data. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support and upgrades are available as a retainer.
How we scope
- The written scope names the source v3 version, the target v4 release and each store to size and back up.
- Scope confirms ClickHouse 25.12 or later, PostgreSQL 15 or later and Redis 7.0 or later are in place.
- Scope sets the roughly 3x ClickHouse disk headroom for backfill, the write mode and the SDK versions.
How we build
- Finish v3 background migrations and confirm they are complete before any v4 schema change.
- Test the legacy and dual write modes set by LANGFUSE_MIGRATION_V4_WRITE_MODE in a staging copy.
- Move SDK and evaluator code off legacy batch ingestion and trace-level evaluators before cutover.
How we hand over
- Written runbook covering the cutover sequence, the backfill steps and the decision points for rollback.
- Verification record showing trace ingestion, scores and exports checked after cutover, with legacy export dependencies listed.
- Handover of configuration, version pins and open items to your operations team.
How we support
- Optional retainer covers later Langfuse releases, SDK version changes and security patch windows.
- Retainer scope, response times and any SLA are agreed in writing before they apply.
- Langfuse's Self-Hosted Enterprise plan adds a named support engineer and an SLA, which you can compare with a retainer.
