Moving self-hosted Langfuse from ClickHouse OSS to ClickHouse Cloud or BYOC
If your team runs self-hosted Langfuse on its own ClickHouse OSS and now wants ClickHouse Cloud or a bring-your-own-cloud (BYOC) deployment, you are making a documented deployment-model change, and it requires an ingestion pause. The effort depends on how much data you hold, which copy method you use and how cleanly your current environment is configured. Langfuse advises running the latest release unchanged during the move, so the migration should not also carry a version change. DeployOpen plans and executes this work under a written scope, so the boundaries of the move are agreed before anyone touches production. The goal is to keep historic traces, observations and scores in the new ClickHouse environment while Langfuse Web and Langfuse Worker keep serving the same users. Your ClickHouse is one of several stateful components in the deployment, alongside PostgreSQL, Redis or Valkey and S3-compatible blob storage. Only the ClickHouse connection changes in principle, but the consequences reach every place that holds a connection string, credential or SSL setting, so you need an inventory of those before you schedule anything.
Decisions to make first. Confirm the target: ClickHouse Cloud, or BYOC inside your own cloud account. Decide which copy method fits your data volume and network path. Langfuse documents two options: remoteSecure, which copies data over a secure connection between clusters, and BACKUP and RESTORE through object storage. Ask the vendor or your own ClickHouse administrator whether your current version and target service support both paths for your configuration. Also agree on the maximum acceptable ingestion pause with the teams that send traces, because Langfuse says a live dual-write cutover has not been validated and you should plan for a pause instead. Decide who owns each step: the platform team for the Langfuse containers and secrets, the data team for the copy and its verification, and the security team for network paths, credentials and encryption at rest in the new environment.
Preparation to run before the window. Record the current values of CLICKHOUSE_URL, CLICKHOUSE_MIGRATION_URL, the ClickHouse credentials and the SSL settings, and store them in your secrets manager. Check free disk space on the source and target, because the copy and any backup staging need room. DeployOpen's experience is that unclear disk headroom is a common source of delay, so measure it rather than estimate it. Confirm that the target ClickHouse version meets the Langfuse release you run, and confirm the network routes between the Langfuse containers, the source cluster, the target cluster and object storage if you use BACKUP and RESTORE. Run a rehearsal in a non-production environment with a copy of recent data. Record the time each step takes so you can plan the production window from measured results.
Cutover and verification. During the pause, scale down langfuse-web and langfuse-worker, run the copy, then update the connection values and restart the containers. Verify that the trace count, observation count and score count in the target match the source for a sample of projects and time ranges, and check that new ingestion lands in the target. Confirm the migration job completes on the target and that the UI shows historic traces for a known project. Keep the source cluster intact until you have confirmed the target for an agreed period and have a tested way back if verification fails. Do not decommission the source during the window.
What to ask for in a written scope. Ask for the inventory of configuration values, the chosen copy method with its rationale, the rehearsal plan and results, the production runbook, the rollback path, the verification queries and the handover of ClickHouse operations on the target. Keep the Langfuse version fixed for the whole project, and treat any major upgrade as a separate engagement with its own plan.
What carries over from ClickHouse OSS and what needs a plan
This table maps each part of a source ClickHouse OSS deployment to how it is handled on ClickHouse Cloud or BYOC. Read the treatment column to see whether an item copies as data during the paused copy, must be set in Langfuse environment variables, or needs a check after cutover. Items outside the documented copy path are marked for verification instead of being assumed to move.
| Item | Where it sits | Treatment after cutover |
|---|---|---|
| Traces, observations and scores | ClickHouse tables | Copies as data during the paused ingestion window, using remoteSecure or BACKUP and RESTORE through object storage |
| Schema and migration state | ClickHouse schema and migration tracking | Copies with the database, then point CLICKHOUSE_MIGRATION_URL at the new cluster and verify |
| Connection endpoint | CLICKHOUSE_URL | Reconfigure in Langfuse environment variables |
| Credentials | ClickHouse user and password | Reconfigure in environment variables, then confirm the new user can read and write |
| SSL settings | Secure connection options | Reconfigure in environment variables, then verify the secure connection from both web and worker |
| Events sent during the pause | SDK and OTLP traffic | Verify how events sent during the pause were handled before treating the move as complete |
| PostgreSQL metadata | Projects, users and API keys | Outside the ClickHouse copy, so confirm it is unchanged and still matches the restored trace data |
| Blob storage objects | S3-compatible storage | Outside the ClickHouse copy, so verify stored references still resolve after cutover |
Why the ClickHouse move is a deployment change and not a Langfuse upgrade
Langfuse's documented guidance treats moving a self-hosted deployment from ClickHouse OSS to ClickHouse Cloud or BYOC as a change of deployment model. The team is changing where the analytical store runs, who operates it, and how the application reaches it. The Langfuse version itself is not the thing being changed. Langfuse recommends running the latest release unchanged during the move. For change control, this means the request should be raised as an infrastructure migration with its own risk record, approvals, maintenance window and go or no-go criteria, not as part of a Langfuse release ticket. The change record should state the exact Langfuse image tags for web and worker before and after the move, so that any fault can be traced to the data store change.
The environment changes in five places. First, CLICKHOUSE_URL and CLICKHOUSE_MIGRATION_URL point to new endpoints. Second, the database users and passwords used by the application and by migrations are replaced, which means secret stores, rotation schedules and deployment pipelines must be updated. Third, the SSL settings change, and the team must confirm the exact requirements for the new endpoint with ClickHouse. Fourth, the network path changes: egress from the Langfuse web and worker containers, firewall rules, DNS and any private connectivity all need review. Fifth, operational ownership of ClickHouse moves. Backups, patching, scaling, monitoring and incident response for the database must be assigned in writing to either your team or the service provider, and that split should be confirmed with ClickHouse before the window.
The application version should not change during the move. Keep the Langfuse web and worker images pinned to the same release on both sides of the cutover. Keep PostgreSQL, Redis or Valkey, and S3-compatible blob storage unchanged, and do not alter application configuration that is unrelated to ClickHouse. A pinned version makes the test evidence meaningful: if traces are missing or queries fail after the move, the team can narrow the cause to the connection, the copied data or the new service. Before the window, read the release notes for the pinned version and confirm whether any migration runs at startup. If a startup migration touches ClickHouse, it should be understood and tested on the new instance before the production cutover.
Rollback is the part most often underplanned. Because the move repoints connection settings and copies data, rollback means restoring the original CLICKHOUSE_URL, migration URL and credentials, then bringing the original ClickHouse OSS instance back into service with its data intact. Keep the original instance unchanged until the new instance has been verified, and agree in advance how long it will remain available. Langfuse says a live dual-write cutover has not been validated, so the plan should not depend on writing to both stores at once. Decide before the window what happens to traces produced during the ingestion pause, whether they are queued at the client or lost, and who makes that call.
Record the decisions that the change board will ask for: the named owner of each ClickHouse responsibility, the length of the maintenance window agreed with application teams, the rollback trigger and who can invoke it, and the verification steps that signal success. Keep this migration separate from any major Langfuse upgrade. Major upgrades follow their own migration guides, change the data model and carry their own ClickHouse version requirements. Combining the two removes the ability to tell which change caused a fault, and it doubles the rollback paths the team must test. Schedule them as separate changes, each with its own record and verification.
Choosing between remoteSecure and BACKUP and RESTORE for the copy
The remoteSecure method reads Langfuse tables from the source ClickHouse OSS server and writes them into ClickHouse Cloud or BYOC in one operation, so no intermediate copy is stored between the two environments. It needs a network path that allows the target to reach the source over a secure native connection, a read-capable account on the source and a write-capable account on the target. It suits teams that can open a controlled, approved connection between the two environments for the length of the copy.
- Network: confirm that firewall rules, security groups and any private endpoint routing allow the connection that the guide requires, and that the path is approved by your network team.
- Credentials: use a dedicated read-only source account and a scoped target account, both held in your secrets manager and removed after the copy.
- Transfer duration: a long transfer over an unstable path extends the ingestion pause, so monitor the copy from start to finish.
- Verification afterward: compare row counts and latest timestamps for each Langfuse table between source and target before changing any configuration.
Confirm the exact statements, table list and TLS settings against the Langfuse migration guide before running anything in production.
The BACKUP and RESTORE method has the source write a backup into an object storage location, and the target restores from that same location. It does not need a direct connection between source and target, but both sides need credentials and network access to the bucket, and ClickHouse must be configured to use that storage. It suits teams whose environments are separated by firewalls, or teams that want a retained artifact to support rollback during the cutover.
- Storage placement: a bucket in the region where the target runs usually simplifies access, and the provider bills storage and any cross-region transfer, so ask for those charges in your estimate.
- Credentials: grant the source write access and the target read access, each limited to the backup prefix and nothing else.
- Verification afterward: check the backup job's completion status, the restored row counts per table and the object listing in the bucket.
- Retention and encryption: confirm server-side encryption and access logging on the bucket, and delete the backup once post-cutover checks pass, because it holds trace data outside the database.
Confirm the storage configuration steps and supported bucket options against the Langfuse migration guide and the ClickHouse documentation for your version.
The choice usually depends on four factors: data volume, the network path between source and target, where object storage sits, and how your governance process treats an extra copy. None of these has a fixed threshold in the guide, so the decision should rest on your measured values rather than general rules. Record each factor during planning so the choice can be reviewed later.
- Data volume: larger tables extend the time the ingestion pause stays open, so request current table sizes and row counts from the source before choosing.
- Network path: an approved, direct connection between source and target favors remoteSecure, while separated environments with no approved route favor BACKUP and RESTORE.
- Object storage placement: an existing bucket that both environments can already reach lowers the setup effort for BACKUP and RESTORE.
- Governance: an intermediate backup is another dataset that holds traces, so auditors and data owners may need to approve its location, access and deletion.
Write the decision down with the values for each factor, and name the owner who approved it.
Whichever method you choose, run the full copy in a non-production target built from a recent copy of the source, and measure the end-to-end pause before setting a production window. The rehearsal should use the same Langfuse release that will run in production, because the documented path keeps the release unchanged during the move. Estimates made without a rehearsal often understate the time needed for verification and configuration changes.
- Pause length: time from scaling down web and worker containers to the first successful request against the new ClickHouse endpoint.
- Data scope: table list, row counts and latest timestamps for traces, observations and scores, compared after each run.
- Network or storage throughput: the observed transfer rate between environments, or the time for backup and restore jobs in the chosen storage location.
- Configuration changes: the CLICKHOUSE_URL, CLICKHOUSE_MIGRATION_URL, credential and SSL updates, tested in order, with a documented rollback.
- Credential rotation: the credentials used for the copy, rotated or removed after each rehearsal.
Record the measured pause from the final rehearsal and base the production window on that record, not on an estimate.
Documented copy paths and configuration variables
The documented move from ClickHouse OSS to ClickHouse Cloud or BYOC has four parts that depend on each other: copy the data, stop writes while the copy runs, and then point Langfuse at the new cluster. Each part needs access and settings confirmed before the ingestion window opens. The exact steps belong to the current Langfuse migration guide, so check them against the Langfuse release you run.
The remoteSecure copy
The remoteSecure table function reads ClickHouse data from the source server over a secure connection and writes it into the target. Confirm that the source can reach the target over the port and network path your environment allows, and that the target account can create and insert into the tables in scope. List every database and table that holds traces, observations and scores so nothing is left behind. Confirm the exact statement form against the current migration guide and your ClickHouse release before the window opens.
BACKUP and RESTORE through object storage
BACKUP writes the source data to an object storage location, and RESTORE reads it into the target ClickHouse Cloud or BYOC cluster. Confirm that the bucket exists, that the source can write to it, and that the target can read from it, with credentials scoped to that path only. Check whether your storage is reachable from the target service, how backup paths are named, and who owns the retention of the copied files. Restore a small table first and compare row counts with the source before running the full copy.
Scaling down web and worker containers
Scaling down the Langfuse web and worker containers stops ingestion, so SDKs and OTLP senders will fail or queue on their side until the cutover completes. Confirm how your deployment method sets replica counts, whether that is Kubernetes deployments, Helm values or Docker Compose service settings, and who can change them during the window. Agree with application teams how their clients behave when the endpoint is unavailable and whether buffering is in place. Sequence the scale down, the copy and the scale back up as one runbook.
CLICKHOUSE_URL, migration URL and credentials
After the copy, CLICKHOUSE_URL must point to the new ClickHouse Cloud or BYOC endpoint, and CLICKHOUSE_MIGRATION_URL must be checked so the migration connection also targets the new cluster. Credentials and SSL settings change with the endpoint, so confirm the database user, how the password is stored and whether the target requires TLS in the form you configure. Confirm the exact variable names in your Langfuse release and how your deployment method injects them, such as a Kubernetes secret, Helm values or an environment file. Name the person who stores the new credentials.
How a planned ingestion pause runs from inventory to cutover
This sequence moves a self-hosted Langfuse from ClickHouse OSS to ClickHouse Cloud or BYOC while keeping historic traces, observations and scores. It ends with a verified target and a retired source. Langfuse says a live dual-write cutover has not been validated, so the plan includes a scheduled ingestion pause, and a rehearsal can only prove part of what the final copy will do.
Inventory the source deployment and release
Record the Langfuse release and deployment method currently running, the ClickHouse OSS version, table sizes, disk use, retention settings and any Enterprise features in use. Retention and audit configuration must carry over to the new setup, so list them explicitly. Agree with the client that the target will run the latest Langfuse release without changes, and keep any major version upgrade as a separate project. Done when the client signs off the inventory and the release is fixed for the move.
Size the ClickHouse target and network path
Size the ClickHouse Cloud service or BYOC cluster from the inventory, including storage for the copied history and headroom for ingestion that continues after the move. Map the network path from the Langfuse web and worker containers to the target, covering private connectivity, allowed address ranges and TLS. Confirm the copy method with ClickHouse before the rehearsal, because the documented paths use remoteSecure or BACKUP and RESTORE through object storage. Done when the target accepts a test connection from the Langfuse network and the sizing is approved.
Rehearse the copy in a non-production target
Copy the source data into a non-production ClickHouse target using the method planned for cutover, and run the same Langfuse release against it. Compare row counts for traces, observations and scores in each table, then spot-check sample records by ID in the UI and API. Record every command and error so the production runbook is exact. Done when counts match for each table in scope and the team has a written list of differences to resolve. The rehearsal proves the method, the runbook and the target configuration, but it cannot reproduce production write load or the final delta written during the pause.
Pause ingestion by scaling down web and worker
Schedule the pause with every team that sends traces, because OTLP and SDK calls made during the pause will fail unless their senders buffer or retry. Scale the Langfuse web and worker deployments down so no new events reach ClickHouse OSS. Confirm the worker queues have drained by checking worker logs and the Redis or Valkey state, then confirm the source tables stop changing across two counts taken a short interval apart. Done when the source is quiescent and the senders have been told the pause has started.
Run the final copy during the pause
Run the production copy with the method proven in the rehearsal, moving all historic data in scope and any data written since the rehearsal snapshot. Keep a copy log with start and end times, the commands used and per-table counts. Because the pause is planned, a failed table can be rerun without changing live data in the middle of a write. Done when source and target counts match for every table in scope and the client's data owner signs the copy log.
Update the configuration and restart Langfuse
Update CLICKHOUSE_URL, CLICKHOUSE_MIGRATION_URL, the ClickHouse credentials and the SSL settings so the web and worker containers point at the target. Keep the change in version control and review it with the client's security team before deployment. Start the web and worker containers and watch the startup logs for migration checks and connection errors. Done when both containers report healthy and the application connects to the target without authentication or TLS errors.
Verify traces, observations and scores
Check sample historic records from the inventory in the Langfuse UI and through the public API, and compare the results with the counts recorded during the rehearsal. Send a test trace through the OTLP endpoint and confirm it appears with its observations and scores. Restart sending applications and confirm that new traces arrive in the target. Done when the client signs the verification checklist and the ingestion pause is recorded as ended.
Decommission ClickHouse OSS after the retention window
Keep ClickHouse OSS unchanged and available for rollback through the retention window the client sets, and take a final backup before any change. Do not remove the source until the client confirms in writing that the target is the system of record. Then remove the old service, its volumes and its credentials, and log the deletion. Done when the decommission record shows the source removed and the final backup stored under the client's retention policy.
What drives the cost and duration of the move
This table lists the factors that change the effort of moving self-hosted Langfuse from ClickHouse OSS to ClickHouse Cloud or BYOC, and whether each one raises cost, extends the schedule, or does both. Use it to confirm that a written quote addresses every driver. The main takeaway is that data volume, the copy method and the ingestion pause the business accepts usually set most of the schedule.
| Driver | Raises cost, duration or both | Why it changes the work | What to ask for in a written quote |
|---|---|---|---|
| Historic data volume in ClickHouse | Both | Larger trace, observation and score tables take longer to copy, verify and restore. | The data size assumed, the table list, and how the estimate was measured in your environment. |
| Copy method (remoteSecure or BACKUP and RESTORE) | Both | remoteSecure copies over a live network link, while BACKUP and RESTORE stages the data in object storage first. | The method proposed, the reason for it, the storage needed, and the rollback path if the copy fails. |
| Network path and bandwidth between source and target | Duration | Transfer speed depends on the route, encryption overhead, and any proxies or firewall rules between the two sites. | A network diagram, the bandwidth assumed, and who tests the path before the cutover window. |
| Target ClickHouse disk and memory headroom | Both | Restores need free disk and memory. An undersized target forces resizing or slower retries during the pause. | Target sizing checked against Langfuse scaling guidance, the disk headroom assumed, and who pays for any resizing. |
| Number of Langfuse environments and projects | Both | Each environment repeats the copy, validation and configuration change, and shared instances need extra checks. | The count of environments in scope and whether each one is scheduled and costed separately. |
| Length of the ingestion pause the business accepts | Duration | Langfuse does not validate a live dual-write cutover, so the pause window sets the schedule and the risk. | The agreed pause window, out-of-hours staffing, and what happens if the copy runs past that window. |
| SSO and secrets rotation | Cost | New ClickHouse credentials and SSL settings must reach your secrets store, and sign-in must be retested after restart. | Which secrets change, who rotates them, and which SSO and login checks are included. |
| Monitoring and backup changes | Cost | Dashboards, alerts and backup jobs that point at the old ClickHouse must be repointed and then proven to work. | An inventory of monitors and backup jobs to update, and whether a restore test is included. |
| Team's ClickHouse operations experience | Both | Teams new to running ClickHouse Cloud or BYOC need more review time, and errors during restore are costlier to fix. | The ClickHouse skills involved, whether knowledge transfer is included, and what support follows handover. |
What usually goes wrong during a ClickHouse move and how to prevent it
Most failures in this move come from three places: the ingestion window, the copy itself, and the configuration that changes at cutover. Each card names one failure point, the documented step that reduces it, and a check the team can run before traffic returns to the new ClickHouse.
Ingestion pause runs long
The documented path stops ingestion by scaling down the web and worker containers, so trace data sent during the window may be delayed or dropped, depending on whether your applications retry. Langfuse states that a live dual-write cutover has not been validated, so treat the pause as a scheduled window agreed before the copy starts. Confirm with your team how long the copy will take on your data volume, set a stop time, and agree a go or no-go check before scaling down.
Copy finishes with missing data
A copy job can report success while some tables, partitions or recent rows are absent, and the gap often surfaces only when someone queries older history. Prevent this by choosing one supported method, remoteSecure or BACKUP and RESTORE through object storage, and letting it run to completion before any traffic moves. Verify by comparing row counts and table lists for traces, observations and scores between source and target, then spot-checking a sample of traces in the UI.
Stale credentials or SSL settings
The cutover changes CLICKHOUSE_URL, CLICKHOUSE_MIGRATION_URL, ClickHouse credentials and SSL settings. If any one of them still points at the old instance in the web, worker or migration path, a container may fail to start or write to the wrong place. Before the window, list every container and environment variable that references ClickHouse. After the change, check container logs for connection or certificate errors and send one test trace end to end.
Bundled stores or hostnames not updated
If your Helm deployment bundles ClickHouse or another data store, values files and secrets may still reference old service names or hostnames after the move to Cloud or BYOC. Confirm how your chart version exposes ClickHouse settings, then render the chart templates and compare them with the running release. Verify that the rendered values match the new endpoint and that no pod resolves the old hostname.
Disk headroom shortfall on target
The target needs space for the copied history plus working room during the restore. The Langfuse v3 to v4 upgrade guide advises about 3x ClickHouse disk headroom when backfilling historic data, and that figure is a useful planning reference for a large copy. Confirm the storage size your own data needs with your ClickHouse provider, and check free disk space and background merge activity on the target after the copy and before resuming ingestion.
Combined upgrade hides the cause
Pairing the move with a major Langfuse upgrade means a fault could come from the new data model, a newer ClickHouse version requirement, or the new infrastructure, and the team cannot tell which. Langfuse recommends running the latest release unchanged during the move and keeping it separate from a major version upgrade. Record the running version before the window, keep it the same through cutover, and schedule any major upgrade only after the move is verified.
Why not combine the ClickHouse move with a major Langfuse upgrade
Langfuse advises keeping the move from ClickHouse OSS to ClickHouse Cloud or BYOC separate from a major version upgrade. The move changes the deployment model and the data path: ingestion pauses, the database is copied, and CLICKHOUSE_URL, CLICKHOUSE_MIGRATION_URL, credentials and SSL settings change. A major upgrade changes the software and the schema. Langfuse's v3 to v4 guide moves ClickHouse to an observations-first data model and sets new floor versions. If both changes land in one window and the cutover fails, the team cannot easily tell which change caused the problem, and rollback becomes a choice between two unrelated recovery paths.
The v4 requirements are a planning input before any change is scheduled. The guide requires ClickHouse 25.12 or later, recommends 26.4, and requires PostgreSQL 15 or later and Redis 7.0 or later. The target ClickHouse Cloud or BYOC service must meet the ClickHouse floor, and the platform team should confirm whether the copy also moves the data to a newer version. The guide also advises about 3x ClickHouse disk headroom for backfilling historic data. Helm users with bundled data stores must upgrade the chart from v1 to v2 before upgrading to v4. Confirm each of these against the guide for your target release, and size the disk for the backfill before the window opens.
There are three sequencing options. First, move on the current release, then upgrade later. This keeps the rollback point simple: while ingestion is paused, the OSS ClickHouse still holds the full history, so the team can point CLICKHOUSE_URL back to it. After ingestion resumes on Cloud or BYOC, returning to OSS means copying new data back. Second, upgrade first on the OSS ClickHouse, then move. This needs the ClickHouse floor met on the old cluster, and rollback after the schema change depends on whether the upgrade guide supports reverting it, so confirm that with Langfuse first. Third, combine both. This gives the fewest pauses but the widest rollback surface and the hardest diagnosis, and Langfuse's guidance argues against it.
Before planning, confirm the Langfuse release you will target. The GitHub releases page listed v4.63.0, published October 16, 2026, at the time these facts were gathered, so check that page for the current release and read the upgrade guide version that matches it. Also confirm the matching SDK versions: Python SDK v5 and JS/TS SDK v6 need Langfuse v4.59.0 or later. Write down the rollback point for the option you choose, the date after which reverting means restoring from backup, and who approves that decision. Those answers, not the calendar, decide whether the move and the upgrade can share a window.
Questions teams ask before moving Langfuse off ClickHouse OSS
How much does moving self-hosted Langfuse to ClickHouse Cloud cost?
No public figure applies here, so the quote follows from the written scope. Costs fall into three groups. The ClickHouse Cloud or BYOC infrastructure is paid to ClickHouse or your cloud provider and recurs. The engagement fee for planning, the copy, verification and cutover is one-time and is paid to DeployOpen under a fixed scope. Your internal time for access, approvals and testing is also one-time. The main drivers are the amount of trace history to copy, whether you use the remoteSecure path or BACKUP and RESTORE through object storage, the number of environments, and whether the move is bundled with other work. Ask the quote to show each line separately, with what is one-time, what recurs, and which charges are yours.
How long does the ingestion pause last during the move?
The pause is set by the copy and verification work in your environment, not by a fixed duration. During the pause, the Langfuse web and worker containers are scaled down, so new traces are not ingested until the connection settings point at the new ClickHouse. The copy uses remoteSecure or BACKUP and RESTORE through object storage, and both take longer as data volume grows and as network throughput between source and target falls. Verification of row counts and a test trace before reopening adds time too. Ask for a timeline in the written scope that states the assumed data volume, the copy method and the rehearsal plan. Agree the window with your application owners before work starts.
What does our team need to provide for the move?
Your team provides access, approvals and decisions. You need ClickHouse access on both the source and the target, including credentials, network routes and any allowlists between the self-hosted cluster, ClickHouse Cloud or BYOC, and the object storage used for the copy. Network changes, firewall rules and private endpoints must be approved by your network and security owners. You also need a change window that covers the ingestion pause, a named owner who signs off on the pause and the rollback point, and staff who can confirm that traces and scores look correct after cutover. Application teams should know when tracing stops and when it resumes.
Can our own team move Langfuse to ClickHouse Cloud without a partner?
Yes, if your team already runs ClickHouse, Langfuse and the container platform. The documented path is a sequence of ordinary steps: scale down, copy, update settings, restart and verify. The skills that matter most are ClickHouse administration (users, network access, backup and restore, TLS), operating the Langfuse web and worker containers, and planning a rollback. Teams that have not restored a ClickHouse backup before often find the copy and verification stages take the most care. A partner adds a written scope, rehearsal in a non-production environment, a cutover checklist and evidence for change records. Decide by comparing these skills with the time your staff can commit to the window.
Can Langfuse switch to ClickHouse Cloud with no ingestion pause?
Not on a validated basis. Langfuse states that a live dual-write cutover has not been validated, so the documented plan assumes an ingestion pause. Plan a window in which the web and worker containers are scaled down and the copy and switch finish before ingestion resumes. Traces sent during the window may be queued or lost depending on your SDK and client configuration, so confirm this with your instrumentation owners. Whether your applications can tolerate missed or delayed traces is a decision for your application and platform owners, and it should be recorded in the sign-off. If zero interruption is a hard requirement, raise it during scoping, because any alternative approach would need its own design and testing first.
Should we combine the ClickHouse move with a Langfuse major upgrade?
No. Langfuse recommends running the latest release unchanged during the move and advises keeping the move separate from a major version upgrade. Combining them makes it hard to tell whether a failure came from the new ClickHouse deployment or from the data model change. The v3 to v4 guide requires ClickHouse 25.12 or later, recommends 26.4, moves to an observations-first data model, and advises about 3x ClickHouse disk headroom when backfilling historic data. Plan the move first, then schedule the upgrade in its own window with its own rollback point. Confirm the order against the release notes and migration guide for your version.
Which settings change in Langfuse after the ClickHouse copy?
The main changes are the connection and credential settings that point Langfuse at the new ClickHouse: CLICKHOUSE_URL, CLICKHOUSE_MIGRATION_URL, the database credentials and the SSL settings. The documented path updates these after the copy completes, then restarts the web and worker containers so they read the new values. Engineers should confirm that both URL variables point at the new endpoint, that TLS is enforced with the expected certificate chain, and that the Langfuse containers can reach ClickHouse on the required ports from their network segment. Record the previous values for rollback, and check the documentation for your Langfuse version for any other variables that must match.
How DeployOpen scopes, runs and supports the ClickHouse move
DeployOpen treats the move from ClickHouse OSS to ClickHouse Cloud or BYOC as a deployment-model change inside a self-hosted Langfuse. We fix the scope in writing first, then run the documented path with a planned ingestion pause, a verified copy and a controlled switch of connection settings.
How we scope
- Written scope lists the Langfuse release, ClickHouse versions, and the tables and retention window to be carried over.
- Scope records whether the copy uses remoteSecure or BACKUP and RESTORE through object storage, with reasons.
- Ingestion pause window, owner sign-off and rollback point are agreed before any work starts.
How we build
- Run the latest Langfuse release unchanged during the move, keeping it separate from any major version upgrade.
- Stage the target ClickHouse Cloud or BYOC environment and test connectivity, credentials and SSL settings first.
- Scale down web and worker containers, copy the database, then update CLICKHOUSE_URL, CLICKHOUSE_MIGRATION_URL and credentials.
How we hand over
- Verify row counts and sample traces, observations and scores in Langfuse against the source before cutover.
- Document the final connection settings, the copy method used, the pause timing and the rollback steps.
- Deliver a runbook for ongoing operations, covering backups and disk headroom on the new ClickHouse deployment.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Confirm with your team and with ClickHouse which Cloud or BYOC options, regions and support terms apply to your account.
