Langfuse ClickHouse sizing and operations guide

Why Langfuse ClickHouse sizing decides whether tracing keeps up

Provision ClickHouse for the trace volume and retention you expect over the next upgrade cycle, not for the first week of testing. The Langfuse scaling guide lists 2 CPU and 8 GiB as the minimum for ClickHouse and advises at least 16 GiB of memory for larger deployments, but those figures are starting points rather than a sizing answer. Your number depends on how many traces and observations you ingest each day, how long you keep them, and how heavily your team queries dashboards and the API. Write those three inputs down as figures your engineering and compliance leads agree on before you choose any instance size or disk.

ClickHouse holds the analytical trace data in a self-hosted Langfuse deployment, so it drives most of the memory, disk and upgrade planning for the data tier. Its footprint grows with every trace you send, which makes ingestion rate and retention window the variables that matter, not the number of users in the UI. Version planning belongs here too. The v3 to v4 upgrade guide requires ClickHouse 25.12 or later and recommends 26.4, so a ClickHouse upgrade is a separate change with its own compatibility check, backup and rollback plan. Confirm the version your target Langfuse release needs before you commit to a database image.

The hard part is planning for growth and backfill, not the day-one install. A Langfuse deployment that runs well on its first day can still fall behind once volume rises or once a major upgrade rebuilds history. The v3 to v4 guide advises about 3x ClickHouse disk headroom when backfilling historic data, so a migration that reprocesses existing traces needs room for the source data, the new structures and temporary working space. Ask your team to model disk use over the full retention period, add the backfill allowance on top, and confirm whether a backfill is planned at all. Treat that headroom as a budget line to approve early, because disk expansion in a live cluster is harder to schedule than it is to request.

Single-VM test setups do not tell you what production needs. Langfuse documents Docker Compose on a single virtual machine for testing, and that setup has no high availability. The scaling guide and deployment docs point production teams toward Kubernetes with Helm or Terraform-based deployments on AWS, Azure or GCP. Use the test environment to confirm configuration and version compatibility, then run a load test on a production-like cluster with trace volume close to your expected peak. Watch ClickHouse memory and disk, worker CPU load and ingestion delay during that test, because a lag in ingestion usually appears before storage fails outright.

Which ClickHouse settings and components the sizing touches

Langfuse spreads work across several containers and data stores, and each one affects ClickHouse load differently. The worker writes to ClickHouse, the web container reads from it, and the queue, metadata and blob stores set how quickly that work moves. Start with the ClickHouse minimums, then check each component's role before you set replica counts or disk budgets.

ClickHouse minimum resources

ClickHouse stores the trace and observation data and answers every query, so it sets the ceiling for the whole deployment. Langfuse's scaling guide lists 2 CPU and 8 GiB as the minimum for ClickHouse and recommends at least 16 GiB of memory for larger deployments. Confirm the CPU and memory actually allocated to the ClickHouse container or node, not only the host, and identify which tier your expected trace volume falls into before you choose an instance size.

Worker write path

Langfuse Worker processes asynchronous events and writes ingested trace, observation and score data into ClickHouse. Its write rate follows how fast events arrive, so ingestion bursts reach ClickHouse through the worker first. Langfuse recommends scaling worker containers on CPU load, so watch worker CPU during peak ingestion and add replicas before the processing backlog grows. Each added worker increases insert pressure on ClickHouse, so size the database with the worker count in mind.

Web query path

Langfuse Web serves the user interface and public APIs, and it runs the read queries that load traces, dashboards and scores from ClickHouse. Heavy interactive use or large API queries add read load even when ingestion is quiet. Under heavy ingestion, Langfuse recommends splitting langfuse-web into separate ingestion and user interface deployments so that reads and writes stop competing. Check whether these two paths share ClickHouse resources and how many users query traces at the same time.

PostgreSQL application metadata

PostgreSQL holds relational application data such as projects, users and configuration. Trace event volume goes to ClickHouse, so PostgreSQL sizing does not replace ClickHouse sizing. The scaling guide lists 2 CPU and 4 GiB as its minimum, but a slow PostgreSQL still delays both the web and worker containers. Confirm the data ownership and table layout in the self-hosting documentation for your Langfuse version before assuming where a given record is stored.

Redis or Valkey queue

Redis or Valkey sits between the web and worker containers and holds work that is waiting to be processed. The scaling guide lists 1 CPU and 1.5 GiB as its minimum. When workers fall behind ClickHouse writes, queue depth grows, so a rising queue can be an early signal of slow ClickHouse inserts. Confirm the Redis or Valkey version against your target Langfuse release, since the v3 to v4 upgrade guide requires Redis 7.0 or later.

S3-compatible blob storage

S3-compatible blob storage holds data that Langfuse keeps outside the databases, such as uploaded media and staged event payloads. Its size and request rate grow with trace volume, so it belongs in the capacity plan even though ClickHouse carries the query load. Confirm with the self-hosting documentation which payload types go to blob storage in your version. Check that bucket retention, access policies and replication match the backup plan you set for ClickHouse.

Which ClickHouse topology and sizing approach fits your team

This table compares the deployment and hosting choices behind Langfuse's ClickHouse database and what each one asks of your team after go-live. Read each row against your environment: the options are not mutually exclusive, and the operational cost column is where most ownership decisions are made.

Option	When it fits	Operational cost to own	What to confirm
Single VM with Docker Compose	Evaluation, demos and short-lived test environments where downtime is acceptable	Your team patches the host, manages ClickHouse data on local disk, runs backups and rebuilds after failure. Langfuse documents this path for testing without high availability	Whether the VM disk and backup routine meet your retention needs before any real trace data arrives
Kubernetes with Helm or Terraform	Production deployments that need replicas, rolling updates and infrastructure defined as code on AWS, Azure or GCP	Your platform team owns cluster upgrades, storage classes, resource limits, secret handling and chart version pinning, in addition to the database itself	Which chart and version your Langfuse release expects, and whether bundled ClickHouse is acceptable for your scale
Self-managed ClickHouse node	Teams with ClickHouse operating skills who want full control over version, configuration and storage layout	Your team owns patching, version upgrades, backups, failover and capacity monitoring. Failover is entirely your responsibility	Your chosen ClickHouse version against the minimum Langfuse v4 requires, and your restore procedure tested end to end
Managed ClickHouse in the same cloud account	Teams that want the provider to handle host maintenance while keeping data inside their own account and network	Your team still owns Langfuse configuration, schema compatibility, access policy and restore testing. Provider-side patching and failover depend on the service tier you buy	Supported ClickHouse versions, backup and point-in-time options, private networking and the maintenance window the provider applies
Single ClickHouse instance	Early or moderate trace volumes where one node meets memory and disk planning with headroom for backfill	Lowest coordination effort, but any node outage stops ingestion and queries until recovery. Backfill and upgrades share the same disk and memory	Memory and disk headroom against your expected volume, and whether ingestion lag is acceptable during restarts
Clustered ClickHouse layout	Large trace volumes, strict availability targets or workloads that must keep serving during maintenance	Your team owns replica coordination, keeper or coordination service health, shard and replica balancing, and more complex upgrade sequencing	Whether Langfuse's configuration supports your cluster topology for your version, and the replication setup your team can operate
Backfill during major upgrades	Teams moving from v3 to v4 with historic data they need to keep queryable	Temporary extra disk is needed. Langfuse advises about 3x ClickHouse disk headroom when backfilling, so plan capacity before the upgrade window	Your current data size, the backfill duration in a test environment and whether you can run it outside peak hours

How much memory Langfuse ClickHouse needs and how disk grows

Plan ClickHouse memory and disk from four drivers: how many traces and observations you ingest, how large each payload is, how long you keep data, and how many users and API clients query it at the same time. Langfuse's scaling guide lists 2 CPU and 8 GiB of memory as the minimum for the ClickHouse container, and it advises at least 16 GiB for larger deployments. Treat those figures as the starting floor for your sizing discussion, not as a finished design. Before you choose instance sizes, ask your team to estimate which tier your expected load falls into and to record that assumption in the implementation plan.

Memory use depends heavily on query shape and concurrency. Dashboards in the UI and scripted calls to the public API both run queries against ClickHouse, and long exports can compete with ingestion for memory and CPU. Payload size matters in two ways. Large prompts, completions and tool outputs increase the memory needed for each insert and the bytes written to disk. Identify which teams will open heavy trace views, and whether any service will pull large date ranges through the API on a schedule. Those access patterns often decide whether the 8 GiB minimum holds, more than the average trace count does.

Disk growth follows a simple relationship: ingest rate multiplied by average stored size per trace, multiplied by retention period, adjusted for how well ClickHouse compresses your data. The public guidance does not give per-trace storage figures, because compression and payload mix vary widely between applications. Build the estimate from a load test. Instrument a representative application, send traffic at your expected sustained and peak rates for a defined period, then measure bytes on disk per day using ClickHouse system tables. Repeat the test with sanitized prompts that resemble your production traffic, since prompt size is often the largest variable.

Retention is the control with the largest effect on disk. The Langfuse license key documentation lists data retention policies among the features that need an Enterprise license key, so confirm with Langfuse whether your edition can delete old data automatically before you assume it. If it cannot, plan disk for the full retention period you need or design a deletion process with your team and test it on a copy of the data. Whatever the edition, set disk usage alerts at thresholds that leave time to add storage, and review actual growth against your load test results after the first month of production traffic.

Build sequence for a ClickHouse layer that can absorb a backfill

This sequence takes the ClickHouse layer from version pairing to a go-live state that can absorb a historic backfill without running out of disk. Each step ends with a check the team can run before moving on. The order matters because disk and memory decisions depend on the measured trace volume and the Langfuse version chosen.

Confirm the Langfuse and ClickHouse versions
The platform owner confirms which Langfuse release will run and which ClickHouse release it requires. The v3 to v4 upgrade guide requires ClickHouse 25.12 or later, recommends 26.4, and also requires PostgreSQL 15 or later and Redis 7.0 or later. Helm users with bundled data stores must move the chart from v1 to v2 before Langfuse moves to v4. Confirm SDK compatibility too, since Python SDK v5 and JS/TS SDK v6 need Langfuse v4.59.0 or later. Closing check: run SELECT version() against the ClickHouse node and record the output with the chosen Langfuse release in the change record.
Size the ClickHouse node from measured volume
Measure current or pilot trace volume over a representative window, including trace and observation counts and payload sizes. Langfuse's scaling guide lists 2 CPU and 8 GiB as minimum ClickHouse resources, and at least 16 GiB of memory for larger deployments. Use the measured volume to decide where the node sits relative to those figures, and ask the partner to show the calculation behind the choice. Closing check: a written sizing sheet that links measured volume to the chosen CPU and memory, signed off by the data platform owner.
Provision disk with backfill headroom
Langfuse's v4 upgrade guide advises about 3x ClickHouse disk headroom when backfilling historic data. Start from the steady-state estimate for retained data, then apply the headroom to the portion that will be backfilled so the volume can hold both migrated history and new ingestion. Confirm retention settings first, because longer retention raises the base figure. Ask the storage team whether the volume can be expanded online and how quickly, since headroom only helps if it can be added in time. Closing check: the volume exists with the calculated free space, and the team can read current capacity from the node.
Configure resource limits and storage paths
Set container CPU and memory requests and limits for ClickHouse that match the memory figure on the sizing sheet, and point the ClickHouse data directory at the provisioned volume. Set CPU limits for Langfuse Web and Langfuse Worker so that worker scaling on CPU load behaves as Langfuse recommends. Confirm the PostgreSQL and S3-compatible blob storage connection settings for the chosen deployment method. Closing check: the ClickHouse container reports the configured memory limit, and a query or mount check confirms the data path sits on the new volume.
Deploy and confirm Langfuse connects
Deploy Langfuse Web and Langfuse Worker with PostgreSQL, Redis or Valkey, S3-compatible storage and ClickHouse. Use Kubernetes for production, since Docker Compose on a single VM is documented for testing and has no high availability. Migrations run automatically at startup within a major version, so watch the web and worker logs for completed migrations and any ClickHouse connection errors. Then send a test trace through the public API or the OTLP endpoint. Closing check: the test trace appears in the Langfuse UI and the ingest request returns a success response.
Load test with representative traces
Replay traces that match production shape, including payload sizes, nested observations, scores and the number of projects, through the same ingestion path applications will use. Watch worker CPU, ClickHouse memory and ingestion lag as load increases, and compare the trend with the sizing sheet. Run a test backfill from a sample dataset to confirm that disk use grows within the headroom provisioned. Closing check: a disk usage reading from ClickHouse after the test load that projects the full backfill within the provisioned space, plus a note of the load level where lag began.
Set up backups and monitoring before go-live
Configure ClickHouse backups and test a restore into a separate environment, then confirm backups for PostgreSQL and blob storage, since all three hold Langfuse state. Set alerts on disk free space, ClickHouse memory, worker CPU and ingestion lag, so the team sees a backlog before users report missing traces. Write down which signals mean ingestion is falling behind and who responds to each one. Closing check: a completed restore in the test environment and an alert that fires during a deliberate test, both recorded before go-live approval.

What drives the effort and cost of running ClickHouse for Langfuse

This table lists the factors that move the effort and cost of running ClickHouse behind self-hosted Langfuse, with a way to keep each one under control. Read it as a checklist to bring into scoping, since the size of each driver depends on your traffic, retention needs and infrastructure. Costs come from your own infrastructure and the written scope, not from published figures.

Driver	Why it moves effort or cost	How to keep it down
Trace volume and payload size	Ingestion rate and the size of inputs and outputs set ClickHouse disk growth, memory pressure and worker CPU load.	Decide in the application what to capture, sample high-volume low-value traces and truncate large payloads before sending them over OTLP or the native SDKs.
Retention period	Every day of retained data adds to disk and backup size for the life of the deployment.	Set the retention window with stakeholders before go-live. Data retention policies need an Enterprise license key, so confirm the edition you need before you plan around them.
Number of projects and environments	Each project, plus separate development, staging and production instances, multiplies the data to store, monitor and back up.	Consolidate low-risk environments where your policies allow, and keep production isolated with its own sizing and backup schedule.
Whether a v3 to v4 backfill is needed	Langfuse's v4 guide advises about 3x ClickHouse disk headroom when backfilling historic data, and the backfill adds load while ingestion continues.	Run the backfill in stages, measure disk and ingestion lag between stages, and confirm the required ClickHouse version (25.12 or later, 26.4 recommended) before starting.
Kubernetes versus single host	Docker Compose on a single VM is documented for testing without high availability. Kubernetes with Helm or Terraform is the documented production path, with more components to run and monitor.	Choose the target platform during scoping, then size ClickHouse and worker replicas against that platform rather than retrofitting later.
Managed versus self-managed ClickHouse	A managed service shifts patching, backups and node operations to a provider, while self-managed ClickHouse keeps those tasks, and their evidence, with your team.	Compare the operating model, backup features and support terms of each option in writing. Confirm which controls the provider covers and which remain yours.
Compliance evidence needs	Assessors may ask for proof of backups, restore tests, access control, change records and retention settings, which adds collection and documentation work.	Agree the evidence list before build starts, automate exports where possible and schedule restore tests. DeployOpen prepares evidence, but auditors and certification bodies issue any assurance report.
People on call	The number of people who must respond to ingestion lag, disk alerts and failed upgrades sets the rota size and the runbook depth.	Document the signals to watch, such as ingestion falling behind or disk headroom shrinking, and agree who is on call before go-live.

How ClickHouse sizing changes across single node, HA and Kubernetes

Langfuse documents Docker Compose on a single VM for testing, and this setup has no high availability. All components, including ClickHouse, PostgreSQL, Redis or Valkey, and the Langfuse Web and Worker containers, run on one host. Sizing therefore aims to prove the workflow and the integration, not to sustain production ingestion. The scaling guide lists a minimum of 2 CPU and 8 GiB for ClickHouse, and the same host also carries the other containers, so leave headroom above those minimums.

Sizing: Start at the documented minimums and watch memory during realistic test runs. The guide's guidance of at least 16 GiB of ClickHouse memory applies to larger deployments, so treat it as the signal to leave the single VM.
Storage class: Use the VM's local disk. Confirm its size and performance against your expected test trace volume, because no separate storage tier is available to fall back on.
Backup location: Keep a copy of the ClickHouse data and a snapshot of the VM disk outside the host. Confirm with the team whether test data loss is acceptable.
Upgrade sequencing: Take a snapshot, then apply updates within the current major version. Rehearse any major upgrade on a copy first, including the v3 to v4 requirement for ClickHouse 25.12 or later.

Confirm that no production traffic reaches this host before you rely on it for anything beyond evaluation.

How to test that ClickHouse can ingest, query and recover

Before go-live, the team should prove that the ClickHouse sizing works under load, not just on paper. The verification plan has five parts: a load test with representative traces, a check of ingest lag and query latency in the Langfuse UI, a disk growth check against your planned retention, a restore drill into a separate instance, and a failure test in which ClickHouse is stopped and the worker queues are observed. Each check produces evidence that the team can compare against thresholds it sets in advance. For the load test, build a trace mix that resembles production. Include the input and output sizes you expect, traces with many observations, sessions, user attributes and scores, because these shape both write cost and read cost. Run the mix at your projected peak rate for a sustained period. Watch CPU on the Langfuse Worker containers, since Langfuse recommends scaling workers on CPU load, and record how far behind ingestion falls. Measure ingest lag as the time between an SDK sending a trace and the trace appearing in the UI. Then open the trace list and dashboards with filters that span the full retention window and record the response times. The disk growth check starts from the bytes written per trace during the load test. Multiply that by your projected trace volume and retention period, then compare the result with the disk you provisioned. If you plan a backfill, for example during a v3 to v4 migration, the Langfuse v4 upgrade guide advises about 3x ClickHouse disk headroom for backfilling historic data, so size for that as well. Confirm with your ClickHouse version how merges and compression affect observed disk use, because the first days of data rarely show the steady state. The restore drill proves that backups are usable. Restore the ClickHouse backup into a separate instance, using the same ClickHouse version you run in production, and confirm the restored version meets the Langfuse requirement for your release. Compare record counts and sample traces against the source for a known time range. Restore PostgreSQL and blob storage to matching points as well, because Langfuse depends on references across these stores. Record how long the restore took, since that figure is the basis for your recovery expectations. In the failure test, stop ClickHouse while the load test is running, then watch queue depth on Redis or Valkey and the worker logs. A safe failure means that traces are queued or retried, none are lost, and the UI recovers after ClickHouse returns. Count the traces sent during the outage and confirm that every one is visible after recovery. Confirm the retry and queue behavior for your Langfuse version before running the test, and write the pass criteria for ingest lag, query latency, disk growth, restore time and trace completeness before the first run. Repeat the plan after each major upgrade.

What to monitor, back up and upgrade after go-live

Once Langfuse is live, ClickHouse problems usually appear first as ingestion falling behind, slow dashboards or failed writes. The cards below cover the signals to watch, how to protect the three data stores, how upgrades behave across minor and major releases, and which records your team should keep current so an upgrade or restore does not depend on memory.

Worker queue depth and lag

Langfuse Worker processes events asynchronously, so a backlog shows up there before users notice it. Track queue depth and processing lag over time, not as a single reading. A queue that keeps growing after traffic settles means ingestion is falling behind the ClickHouse write path or the workers lack CPU. Langfuse recommends scaling worker containers on CPU load, so check worker utilization alongside lag before adding replicas.

ClickHouse memory, CPU and disk

Watch ClickHouse CPU and memory for sustained climbs during ingestion peaks, and watch disk usage against the volume limit. Disk is the signal that needs the most lead time, because the Langfuse v3 to v4 guide advises about 3x ClickHouse disk headroom when backfilling historic data. Alert well before the volume fills, and record the thresholds you chose in the sizing record.

Slow queries and failed writes

Slow dashboard queries and failed writes in logs often appear before queue lag does. Review ClickHouse query duration for the trace and observation views your team opens most, and search service logs for insert errors and timeouts. Repeated failures usually point to memory pressure, a merge backlog or disk exhaustion, so correlate them with the resource signals above before treating any single alert in isolation.

Backups for all three stores

Back up ClickHouse alongside PostgreSQL and blob storage, because traces, prompts and stored payloads are only recoverable if all three stay consistent with each other. Confirm with your platform team how ClickHouse backups are taken in your storage layer and how they align with PostgreSQL backups and blob versioning. Then write a restore runbook and rehearse it in a non-production environment, recording the restore steps and timings in the sizing record.

Minor and major upgrade rules

Updates within a major version are non-disruptive and apply database migrations automatically at startup, so each minor release still needs a rollout plan and a tested rollback path. Major upgrades follow their own guides. The v3 to v4 path requires ClickHouse 25.12 or later, with 26.4 recommended, so bring ClickHouse to that version before starting the upgrade. Helm users with bundled data stores must also move the chart from v1 to v2 first.

Version matrix and sizing record

Keep three records current: a version matrix covering Langfuse, ClickHouse, PostgreSQL, Redis or Valkey, the Helm chart and SDK versions, a sizing record with the memory, disk and volume assumptions behind your deployment, and the restore runbook. Update all three at every upgrade. Python SDK v5 and JS/TS SDK v6 need Langfuse v4.59.0 or later, so SDK versions belong in the matrix alongside the server versions.

Questions teams ask before sizing ClickHouse for Langfuse

How much does sizing and operating ClickHouse for Langfuse cost?

The cost comes from three places: infrastructure, internal staff time and any partner work. Infrastructure includes the compute, memory, disk and backup storage for ClickHouse, which recur monthly and grow with trace volume and retention. Staff time covers capacity planning, upgrades and on-call, which recurs. Partner work is one-time for sizing and deployment, if you buy it, and is priced from a written scope. Langfuse's scaling guide sets minimums of 2 CPU and 8 GiB for ClickHouse and at least 16 GiB of memory for larger deployments, so start there. Ask any partner for a quote that separates one-time setup from recurring support, and confirm your cloud costs with your own sizing numbers.

What drives the effort of running ClickHouse for Langfuse?

Trace volume and retention matter most, because they set disk growth, memory pressure and how long backups and restores take. The second driver is ingestion pattern: Langfuse recommends scaling worker containers on CPU load and, under heavy ingestion, splitting langfuse-web into separate ingestion and user interface deployments. Each split adds components to monitor. The third driver is upgrade path. Updates within a major version apply database migrations at startup, while major upgrades follow dedicated migration guides and may require a ClickHouse version change. Effort rises if you run ClickHouse yourself, if you already operate PostgreSQL and Redis differently from the Langfuse defaults, or if you must meet internal evidence requirements. Map these drivers against your environment before you estimate hours.

How long does ClickHouse sizing take before go-live?

The duration depends on how much of the work is new to your team. Sizing needs recent trace volume figures, a target retention period and a decision on whether ClickHouse runs in your Kubernetes cluster or on managed infrastructure. Deployment time depends on your cloud account approvals, network access and how many environments you need, such as test and production. If you are moving from an earlier Langfuse architecture, the v3 to v4 guide adds a data model change and a backfill step that can add weeks of validation. We do not publish a fixed timeline for this work. Ask for a written plan with phases and dependencies, and confirm the upgrade path against Langfuse's upgrade guide before you commit to dates.

What must our internal team provide for ClickHouse sizing?

Two inputs are essential. The first is trace volume data: daily ingestion counts, average trace and observation size, peak periods and the retention period your policy requires. Without these, memory and disk planning rests on guesses. The second is a named on-call owner who can accept alerts for ingestion lag, disk pressure and failed backups after go-live. Also provide cloud account access or a target environment, your Kubernetes or VM standards, identity provider details for SSO, and the approval path for production changes. For backfill planning, confirm how much spare ClickHouse disk you can reserve, since the v3 to v4 guide advises about 3x ClickHouse disk headroom when backfilling historic data. Gather these before the first working session.

Can our platform team run Langfuse ClickHouse without a partner?

Yes, many teams do. Langfuse's self-hosted deployment uses the same codebase as Langfuse Cloud, the core features and APIs are available in the MIT-licensed open source version, and the self-hosting documentation covers Docker Compose for testing and Kubernetes with Helm or Terraform for production. Your team needs experience with ClickHouse, PostgreSQL, Redis or Valkey and S3-compatible storage, plus backup and restore practice. A partner helps where the work is unfamiliar or time-bound: sizing against your trace volume, building the first production deployment, rehearsing a major upgrade, writing runbooks and validating backups. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted platforms inside your own infrastructure, under a written scope. Decide which parts you keep in-house before you request a quote.

How does Langfuse Enterprise support differ from the open source plan?

The Self-Hosted Enterprise plan adds a named support engineer, solutions architect access and a support SLA, and it is custom-priced. It also unlocks features that need an Enterprise license key, including project-level RBAC roles, protected prompt labels, data retention policies, audit logs, server-side data masking, UI customization, the org management API with SCIM and the instance management API. The open source plan keeps the core features and APIs without limits, but you handle support through your own team and any partner you engage. Confirm the exact SLA terms, response commitments and included hours with Langfuse before you assume them. If your team needs audit logs or retention controls for a compliance review, check those license requirements against your evidence plan first.

Which ClickHouse version does Langfuse v4 require for self-hosting?

The Langfuse v3 to v4 upgrade guide requires ClickHouse 25.12 or later and recommends 26.4. It also requires PostgreSQL 15 or later and Redis 7.0 or later. Check these minimums before you size hardware, because a version gap can block the upgrade and force an unplanned change. If you use the Helm chart with bundled data stores, upgrade the chart from v1 to v2 before you move Langfuse to v4. Python SDK v5 and JS/TS SDK v6 need Langfuse v4.59.0 or later, so plan client upgrades alongside the server. The current release listed on the Langfuse GitHub releases page is v4.63.0, published October 16, 2026. Confirm the version you target against that page and the upgrade guide on the day you schedule the change.

How DeployOpen works on this

DeployOpen plans, implements, backs up and documents self-hosted Langfuse inside your own cloud accounts, data centers or air-gapped networks, including the ClickHouse database that stores trace data. Sizing and operations work starts from a written scope, so memory, disk, backfill headroom and backup plans are agreed before build begins. Engagements are fixed-scope, and ongoing support, upgrades and testing are available as retainers.

How we scope

The written scope lists the ClickHouse deployment target, trace volume inputs and the environments covered
Memory and disk plans are documented per environment, including headroom for a future v3 to v4 backfill
Engagements are fixed-scope, so deliverables and timelines are agreed in writing before work starts

How we build

ClickHouse is installed in your infrastructure with resource settings matched to the agreed sizing plan
Langfuse Web and Worker are configured to connect to ClickHouse, PostgreSQL, Redis or Valkey and blob storage
Ingestion is tested under representative load, and the signals that show falling-behind ingestion are recorded

How we hand over

Runbooks cover disk growth checks, memory monitoring, and ClickHouse backup and restore steps
Version requirements for upgrades are recorded, including minimum ClickHouse and PostgreSQL versions for each target release
Backup and restore test results are documented so your team can repeat the procedure on its own

How we support

Ongoing support, upgrades and continuous testing are available as retainers after go-live
Upgrade planning covers ClickHouse disk headroom and backfill steps before any major Langfuse version change
Ask whether a retainer includes ClickHouse capacity reviews, and confirm response expectations in the written agreement

Langfuse ClickHouse sizing and operations